1. 08 Apr, 2017 40 commits
    • Jordan Crouse's avatar
      drm/msm: Reference count address spaces · ee546cd3
      Jordan Crouse authored
      There are reasons for a memory object to outlive the file descriptor
      that created it and so the address space that a buffer object is
      attached to must also outlive the file descriptor. Reference count
      the address space so that it can remain viable until all the objects
      have released their addresses.
      Signed-off-by: default avatarJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      ee546cd3
    • Jordan Crouse's avatar
      drm/msm: Make sure to detach the MMU during GPU cleanup · 9873ef07
      Jordan Crouse authored
      We should be detaching the MMU before destroying the address
      space. To do this cleanly, the detach has to happen in
      adreno_gpu_cleanup() because it needs access to structs
      in adreno_gpu.c.  Plus it is better symmetry to have
      the attach and detach at the same code level.
      Signed-off-by: default avatarJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      9873ef07
    • Archit Taneja's avatar
      drm/msm/mdp5: Enable 3D mux in mdp5_ctl · 3a882143
      Archit Taneja authored
      3D mux is a small block placed after the DSPPs in MDP5. It can merge
      2 LM/DSPP outputs and feed it to a single interface.
      
      Enable 3D Mux if our mdp5_pipeline has 2 active LMs. This check
      will need to be made more specific later when we add Dual DSI
      support with source split enabled. In that use case, each LM feeds to a
      separae INTF, so the 3D mux isn't needed.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      3a882143
    • Archit Taneja's avatar
      drm/msm/mdp5: Reset CTL blend registers before configuring them · 0d1d3e44
      Archit Taneja authored
      Assigning LMs dynamically to CRTCs results in REG_MDP5_CTL_LAYER_REGs
      and REG_MDP5_CTL_LAYER_EXT_REGs maintaining old values for a LM that
      isn't used by our CTL instance anymore.
      
      Clear the ctl's CTL_LAYER_REG and CTL_LAYER_EXT_REGs for all LM
      instances. The ones that need to be configured are configured later
      in this func.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      0d1d3e44
    • Archit Taneja's avatar
      drm/msm/mdp5: Assign 'right' mixer to CRTC state · 8480adac
      Archit Taneja authored
      Dynamically assign a right mixer to mdp5_crtc_state in the CRTC's
      atomic_check path. Assigning the right mixer has some constraints,
      i.e, only a few LMs can be paired together. Update mdp5_mixer_assign
      to handle these constraints.
      
      Firstly, we need to identify whether we need a right mixer or not.
      At the moment, there are 2 scenarios where a right mixer might be
      needed:
      - If any of the planes connected to this CRTC is too wide (i.e, is
        comprised of 2 hwpipes).
      - If the CRTC's mode itself is too wide (i.e, a 4K mode on HDMI).
      
      We implement both these checks in the mdp5_crtc_atomic_check(), and
      pass 'need_right_mixer' to mdp5_setup_pipeline.
      
      If a CRTC is already assigned a single mixer, and a new atomic commit
      brings in a drm_plane that needs 2 hwpipes, we can successfully commit
      this mode without requiring a full modeset, provided that we still use
      the previously assigned mixer as the left mixer. If such an assignment
      isn't possible, we'd need to do a full modeset. This scenario has been
      ignored for now.
      
      The mixer assignment code is a bit messy, considering we have at most
      4 LM instances in hardware. This can probably be re-visited later with
      simplified logic.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      8480adac
    • Archit Taneja's avatar
      drm/msm/mdp5: Stage border out on base stage if CRTC has 2 LMs · 359ae862
      Archit Taneja authored
      If a CRTC comprises of 2 LMs, it is mandatory to enable border out
      and assign it to the base stage.
      
      We had to enable border out also when the base plane wasn't fullscreen.
      Club these checks and put them in a separate function called
      get_start_stage() that returns the starting stage for assigning planes.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      359ae862
    • Archit Taneja's avatar
      drm/msm/mdp5: Stage right side hwpipes on Right-side Layer Mixer · bf8dc0a0
      Archit Taneja authored
      Now that our mdp5_planes can consist of 2 hwpipes, update the
      blend_setup() code to stage the right hwpipe to the left and
      right LMs
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      bf8dc0a0
    • Archit Taneja's avatar
      drm/msm/mdp5: Prepare Layer Mixers for source split · ed78560d
      Archit Taneja authored
      In order to enable Source Split in HW, we need to add/modify
      a few LM register configurations:
      
      - Configure the LM width to be half the mode width, so that
        each LM manages one half of the scanout.
      - Tell the 'right' LM that it is configured to be the 'right'
        LM in source split mode.
      - Since we now have 2 places where REG_MDP5_LM_BLEND_COLOR_OUT is
        configured, do a read-update-store for the register instead of
        directly writing a value to it.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      ed78560d
    • Archit Taneja's avatar
      drm/msm/mdp5: Configure 'right' hwpipe · c26b4f6c
      Archit Taneja authored
      Now that we have a right hwpipe in mdp5_plane_state, configure it
      mdp5_plane_mode_set(). The only parameters that vary between the
      left and right hwpipes are the src_w, src_img_w, src_x and crtc_x
      as we just even chop the fb into left and right halves.
      
      Add a mdp5_plane_right_pipe() which will be used by the crtc code
      to set up LM stages.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      c26b4f6c
    • Archit Taneja's avatar
      drm/msm/mdp5: Assign a 'right hwpipe' to plane state · 7a10ee9b
      Archit Taneja authored
      If the drm_plane has a source width that's greater than the max width
      supported by a SSPP (2560 pixels on 8x96), then we assign a 'r_hwpipe'
      to it in mdp5_plane_atomic_check().
      
      TODO: There are a few scenarios where the hwpipe assignments aren't
      recommended by HW. For example, an assignment which results in a
      drm_plane to of two different types of hwpipes (say RGB0 on left
      and DMA1 on right) is not recommended.
      Also, hwpipes have a priority mapping, where the higher priority pipe
      needs to be staged on left LM, and the lower priority needs to be
      staged on the right LM. For example, the priority order for VIG pipes
      in decreasing order of priority is VIG0, VIG1, VIG2, and VIG3. So, VIG0
      on left and VIG1 on right is a correct configuration, but VIG1 on left
      and VIG0 on right isn't. These scenarios are ignored for now for the
      sake of simplicity.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      7a10ee9b
    • Archit Taneja's avatar
      drm/msm/mdp5: Create mdp5_hwpipe_mode_set · 821be43f
      Archit Taneja authored
      Refactor mdp5_plane_mode_set to call mdp5_hwpipe_mode_set. The latter
      func takes in only the hwpipe and the parameters that need to be
      programmed into the hwpipe registers. All the code that calculates these
      parameters is left as is in mdp5_plane_mode_set.
      
      In the future, when we let drm_plane be comprised of 2 hwpipes, this func
      allow us to configure each pipe without adding redundant code.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      821be43f
    • Archit Taneja's avatar
      drm/msm/mdp5: Add optional 'right' Layer Mixer in CRTC state · b7621b2a
      Archit Taneja authored
      Add another mdp5_hw_mixer pointer (r_mixer) in mdp5_crtc_state.
      This mixer will be used to generate the right half of the scanout.
      
      With Source Split, a SSPP can now be connected to 2 Layer Mixers, but
      has to be at the same blend level (stage #) on both Layer Mixers.
      
      A drm_plane that has a lesser width than the max width supported, will
      comprise of a single SSPP/hwpipe, staged on both the Layer Mixers at
      the same blend level. A plane that is greater than max width will comprise
      of 2 SSPPs, with the 'left' SSPP staged on the left LM, and the 'right'
      SSPP staged on the right LM at the same blend level.
      
      For now, the drm_plane consists of only one SSPP, therefore, it
      needs to be staged on both the LMs in blend_setup() and mdp5_ctl_blend().
      We'll extend this logic to support 2 hwpipes per plane later.
      
      The crtc cursor ops (using the LM cursors, not SSPP cursors) simply
      return an error if they're called when the right mixer is assigned to
      the CRTC state. With source split is enabled, we're expected to only
      SSPP cursors.
      
      This commit adds code that configures the right mixer, but the r_mixer
      itself isn't assigned at the moment.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      b7621b2a
    • Archit Taneja's avatar
      drm/msm/mdp5: Add a CAP for Source Split · 621da7d9
      Archit Taneja authored
      Some of the newer MDP5 versions support Source Split of SSPPs. It is a
      feature that allows us to route the output of a hwpipe to 2 Layer
      Mixers. This is required to achieve the following use cases:
      
      - Dual DSI: For high res DSI panels (such as 2560x1600 etc), a single
        DSI interface doesn't have the bandwidth to drive the required pixel
        clock. We use 2 DSI interfaces to drive the left and right halves
        of the panel (i.e, 1280x1600 each). The MDP5 pipeline here would look
        like:
      
               LM0 -- DSPP0 -- INTF1 -- DSI1
              /
      hwpipe--
              \
               LM1 -- DSPP1 -- INTF2 -- DSI2
      
        A single hwpipe is used to scan out the left and right halves to DSI1
        and DSI2 respectively. In order to do this, we need to configure the
        2 Layer Mixers in Source Split mode.
      
      - HDMI 4K: In order to support resolutions with width higher than the
        max width supported by a hwpipe, we club 2 hwpipes together:
      
      hwpipe1 --- LM0 -- DSPP0
             -   -             \
               -                -- 3D Mux -- INTF0 -- HDMI
             -   -             /
      hwpipe2 --- LM1 -- DSPP1
      
        hwpipe1 is staged on the 'left' Layer Mixer, and hwpipe2 is staged on
        the 'right' Layer Mixer. An additional block called the '3D Mux' is
        used to merge the output of the 2 DSPPs to a single interface.
        In this use case, it is possible that a 4K surface is downscaled and
        placed completely within one of the halves. In order to support such
        scenarios (and keep the programming simple), Layer Mixers with Source
        Split can be assigned 2 hw pipes per stage. While scanning out, the HW
        takes care of fetching the pixels fom the correct pipe.
      
      Add a MDP cap to tell whether the HW supports source split or not.
      Add a MDP LM cap that tells whether a LM instance can operate in
      source split mode (and generate the 'left' part of the display
      output).
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      621da7d9
    • Archit Taneja's avatar
      drm/msm/mdp5: Remove mixer/intf pointers from mdp5_ctl · f316b25a
      Archit Taneja authored
      These are a part of CRTC state, it doesn't feel nice to leave them
      hanging in mdp5_ctl struct. Pass mdp5_pipeline pointer instead
      wherever it is needed.
      
      We still have some params in mdp5_ctl like start_mask etc which
      are derivative of atomic state, and should be rolled back if
      a commit fails, but it doesn't seem to cause much trouble.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      f316b25a
    • Archit Taneja's avatar
      drm/msm/mdp5: Start using parameters from CRTC state · 0ddc3a63
      Archit Taneja authored
      In the last few commits, we've been adding params to mdp5_crtc_state, and
      assigning them in the atomic_check() funcs. Now it's time to actually
      start using them.
      
      Remove the duplicated params from the mdp5_crtc struct, and start using
      them in the mdp5_crtc code. The majority of the references to these params
      is in code that executes after the atomic swap has occurred, so it's okay
      to use crtc->state in them. There are a couple of legacy LM cursor ops that
      may not use the updated state, but (I think) it's okay to live with that.
      
      Now that we dynamically allocate a mixer to the CRTC, we can also remove
      the static assignment to it in mdp5_crtc_init, and also drop the code that
      skipped init-ing WB bound mixers (those will now be rejected by
      mdp5_mixer_assign()).
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      0ddc3a63
    • Archit Taneja's avatar
      drm/msm/mdp5: Add more stuff to CRTC state · bcb877b7
      Archit Taneja authored
      Things like vblank/err irq masks, mode of operation (command mode or not)
      are derivative of the interface and mixer state. Therefore, they need to
      be a part of the CRTC state too.
      
      Add them to mdp5_crtc_state, and assign them in the CRTC's atomic_check()
      func, so that it can be rolled back to a clean state.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      bcb877b7
    • Archit Taneja's avatar
      drm/msm/mdp5: Assign INTF and CTL in encoder's atomic_check() · 502e3550
      Archit Taneja authored
      The INTF and CTL used in a display pipeline are going to be maintained as
      a part of the CRTC state (i.e, in mdp5_crtc_state).
      
      These entities, however, are currently statically assigned to drm_encoders
      (i.e. mdp5_encoder). Since these aren't directly visible to the CRTC, we
      assign them to the CRTC state in the encoder's atomic_check() op.
      
      With this approach, we assign portions of CRTC state in two different
      places: the layer mixer in CRTC's atomic_check(), and the INTF and CTL
      pieces in the encoder's atomic_check() op.
      
      We'd have more options here if the drm core maintained encoder state too,
      but the current approach of clubbing everything in CRTC's state works just
      fine.
      
      Unlike hwpipes and mixers, we don't need to keep a track of INTF/CTL
      assignments in the global atomic state. This is because they're currently
      not sharable resources. For example, INTF0 and CTL0 will always be assigned
      to one drm_encoder. This can change later when we implement writeback and
      want a CRTC to use a CTL for a while, and then release it for others to use
      it. Or, when a drm_encoder can switch between using a single INTF vs
      2 INTFs.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      502e3550
    • Archit Taneja's avatar
      drm/msm/mdp5: Prepare for dynamic assignment of mixers · 894558ec
      Archit Taneja authored
      Add the stuff needed to allow dynamically assigning a mixer to a CRTC.
      
      Since mixers are a resource that can be shared across multiple CRTCs, we
      need to maintain a 'hwmixer_to_crtc' map in the global atomic state,
      acquire the mdp5_kms.state_lock modeset lock and so on.
      
      The mixer is assigned in the CRTC's atomic_check() func, a failure will
      result in the new state being cleanly rolled back.
      
      The mixer assignment itself is straightforward, and almost identical to
      what we do for hwpipes. We don't need to grab the old hwmixer_to_crtc
      state like we do in hwpipes since we don't need to compare anything
      with the old state at the moment.
      
      The only LM capability we care about at the moment is whether the mixer
      instance can be used to display stuff (i.e, connect to an INTF
      downstream).
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      894558ec
    • Archit Taneja's avatar
      drm/msm/mdp5: subclass CRTC state · c1e2a130
      Archit Taneja authored
      Subclass drm_crtc_state so that we can maintain additional state for
      our CRTCs.
      
      Add mdp5_pipeline and mdp5_ctl pointers in the subclassed state.
      mdp5_pipeline is a grouping of the HW entities that forms the downstream
      pipeline for a particular CRTC. It currently contains pointers to
      mdp5_interface and mdp5_hw_mixer tied to this CRTC. Later, we will
      have 2 hwmixers in this struct. (We could also have 2 intfs if we want
      to support dual DSI with Source Split enabled. Implementing that feature
      isn't planned at the moment).
      
      The mdp5_pipeline state isn't used at the moment. For now, we just
      introduce mdp5_crtc_state and the crtc funcs needed to manage the
      subclassed state.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      c1e2a130
    • Archit Taneja's avatar
      drm/msm/mdp5: Remove the pipeline stuff in mdp5_ctl · eda5dbe5
      Archit Taneja authored
      The mdp5_ctl has an 'op_mode' struct which contains info on
      the downstream pipeline.
      
      Grouping these params together in a struct doesn't serve much
      purpose in the code. Maybe there was a plan to expand this
      further that never happened.
      
      Remove the op_mode struct, and place its members directly in
      mdp5_ctl. This will help avoid confusion later when I introduce
      my own verion of a mdp5 pipeline :)
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      eda5dbe5
    • Archit Taneja's avatar
      drm/msm/mdp5: Clean up interface assignment · 36d1364a
      Archit Taneja authored
      mdp5_interface struct contains data corresponding to a INTF
      instance in MDP5 hardware. This sturct is memcpy'd to the
      mdp5_encoder struct, and then later to the mdp5_ctl struct.
      
      Instead of copying around interface data, create mdp5_interface
      instances in mdp5_init, like how it's done currently done for
      pipes and layer mixers. Pass around the interface pointers to
      mdp5_encoder and mdp5_ctl. This simplifies the code, and allows
      us to decouple encoders from INTFs in the future if needed.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      36d1364a
    • Archit Taneja's avatar
      drm/msm/mdp5: Simplify LM <-> PP mapping · a2380124
      Archit Taneja authored
      PingPong ID for a Layer Mixer is already contained in
      mdp5_hw_mixer.
      
      This avoids the need to retrieve PP ID using macros
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      a2380124
    • Archit Taneja's avatar
      drm/msm/mdp5: Start using mdp5_hw_mixer · adfc0e63
      Archit Taneja authored
      Use the mdp5_hw_mixer struct in the mdp5_crtc and mdp5_ctl instead of
      using the LM index.
      
      Like before, the Layer Mixers are assigned statically to the CRTCs.
      The hwmixer(s) will later be dynamically assigned to CRTCs.
      
      For now, ignore the hwmixers that can only do WB.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      adfc0e63
    • Archit Taneja's avatar
      drm/msm/mdp5: Add structs for hw Layer Mixers · 6803c606
      Archit Taneja authored
      Create a struct to represent MDP5 Layer Mixer instances. This will
      eventually allow us to detach CRTCs from the Layer Mixers, and
      generally clean things up a bit.
      
      This is very similar to how hwpipes were previously abstracted away
      from drm planes.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      6803c606
    • Archit Taneja's avatar
      drm/msm/mdp5: describe LM instances in mdp5_cfg · 384dbd8c
      Archit Taneja authored
      The number of Layer Mixers and the downstream blocks (DSPPs and PPs)
      connected to each LM can vary with different MDP5 revisions. These
      parameters are also static.
      
      Keep the per instance LM data in mdp5_cfg. This will avoid the need
      to have macros which identify PP id or DSPP id the LM is connected
      to. We don't configure DSPPs at the moment, but keeping the DSPP
      instance # here might come handy later.
      
      Also add a 'caps' field that identifies features supported by a
      LM instance. Introduce the caps MDP_LM_CAP_DISPLAY and MDP_LM_CAP_WB
      that identify whether a LM instance can be used for display or
      writeback.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      384dbd8c
    • Archit Taneja's avatar
      drm/msm/mdp5: Bring back pipe_lock to mdp5_plane struct · 01f8a969
      Archit Taneja authored
      We'd previously moved the pipe_lock spinlock to the hwpipe struct. Bring
      it back to mdp5_plane. We will need this because an mdp5_plane in the
      future could comprise of 2 hw pipes. It makes more sense to have a single
      lock to protect the registers for the hw pipes used by a plane, rather
      than trying to take individual locks per hwpipe when committing a
      configuration.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      01f8a969
    • Vinay Simha BN's avatar
      drm/msm/hdmi: redefinitions of macros not required · 1225bb2b
      Vinay Simha BN authored
      4 macros already defined in hdmi.h,
      which is not required to redefine in hdmi_audio.c
      Signed-off-by: default avatarVinay Simha BN <simhavcs@gmail.com>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      1225bb2b
    • Archit Taneja's avatar
      drm/msm/mdp5: Update SSPP_MAX value · 87878d26
      Archit Taneja authored
      'SSPP_MAX + 1' is the max number of hwpipes that can be present on a
      MDP5 platform. Recently, 2 new cursor hwpipes were added, which
      caused overflows in arrays that used SSPP_MAX to represent the number
      of elements. Update the SSPP_MAX value to incorporate the extra
      hwpipes.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      87878d26
    • Archit Taneja's avatar
      drm/msm/dsi: Fix bug in dsi_mgr_phy_enable · 8e25a0e2
      Archit Taneja authored
      A recent commit introduces a bug in dsi_mgr_phy_enable. In the non
      dual DSI mode, we reset the mdsi (master DSI) PHY. This isn't right
      since master and slave DSI exist only in dual DSI mode. For the normal
      mode of operation, we should simply reset the PHY of the DSI device
      (i.e. msm_dsi) corresponding to the current bridge.
      
      Usage of the wrong DSI pointer also resulted in a static checker
      warning. That too is resolved with this fix.
      
      Fixes: b62aa70a (drm/msm/dsi: Move PHY operations out of host)
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      8e25a0e2
    • Jordan Crouse's avatar
      drm/msm: Don't allow zero sized buffer objects · 0041ba39
      Jordan Crouse authored
      Zero sized buffer objects tend to make various bits of the GEM
      infrastructure complain:
      
       WARNING: CPU: 1 PID: 2323 at drivers/gpu/drm/drm_mm.c:389 drm_mm_insert_node_generic+0x258/0x2f0
       Modules linked in:
      
       CPU: 1 PID: 2323 Comm: drm-api-test Tainted: G        W 4.9.0-rc4-00906-g693af44 #213
       Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
       task: ffff8000d7353400 task.stack: ffff8000d7720000
       PC is at drm_mm_insert_node_generic+0x258/0x2f0
       LR is at drm_vma_offset_add+0x4c/0x70
      
      Zero sized buffers serve no appreciable value to the user so disallow
      them at create time.
      Signed-off-by: default avatarJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      0041ba39
    • Jordan Crouse's avatar
      drm/msm: Support 64 bit iova in RD_CMDSTREAM_ADDR · 22dd5c14
      Jordan Crouse authored
      Output the upper 32 bits of a 64 bit iova in the RD_CMDSTREAM_ADDR
      section while maintaining backwards compatibility for tools that
      only understand 32 bit iovas.
      Signed-off-by: default avatarJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      22dd5c14
    • Jordan Crouse's avatar
      drm/msm: Pass interrupt status to a5xx_rbbm_err_irq() · 7352fb5a
      Jordan Crouse authored
      The interrupt status was being cleared before processing the handlers.
      a5xx_rbbm_err_irq() was checking the interrupt status again, which would
      likely turn out bad because the interrupt status would be 0 (or at least
      different). Pass the original status to the function instead.
      
      Also, skip clearing RBBM_AHB_ERROR from the interrupt status. The interrupt
      will keep firing until the error source is cleared.  Skip the clear to
      avoid a storm until the error is cleared in a5xx_rbbm_err_irq().
      Signed-off-by: default avatarJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      7352fb5a
    • Jordan Crouse's avatar
      drm/msm: Don't increase priv->num_aspaces until we know that it fits · 36849cc3
      Jordan Crouse authored
      priv->num_aspaces is increased and then checked to see if it still fits
      in the priv->aspace array.  If it doesn't, we warn and exit but
      priv->num_aspaces remains incremented.
      
      Don't incremement the count until we know that it fits in the array.
      Signed-off-by: default avatarJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      36849cc3
    • Jordan Crouse's avatar
      drm/msm: Fix wrong pointer check in a5xx_destroy · 2002c9c3
      Jordan Crouse authored
      Instead of checking for a5xx_gpu->gpmu_iova during destroy we
      accidently check a5xx_gpu->gpmu_bo.
      Signed-off-by: default avatarJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      2002c9c3
    • Daniel Vetter's avatar
      drm/msm: Simplify vblank event delivery · 02efb359
      Daniel Vetter authored
      The core takes care of handling the send_event vs. close() issues, we
      can remove that driver code.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      02efb359
    • Daniel Vetter's avatar
      drm/msm: switch to postclose · 94df145c
      Daniel Vetter authored
      I didn't spot anything that would require ordering here (well not
      anywhere else either), and I'm trying to unify at least modern drivers
      on one close hook.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      94df145c
    • Arnd Bergmann's avatar
      drm/msm: adreno: fix build error without debugfs · 0c3eaf1f
      Arnd Bergmann authored
      The newly added a5xx support fails to build when debugfs is diabled:
      
      drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:4: error: 'struct msm_gpu_funcs' has no member named 'show'
      drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:11: error: 'a5xx_show' undeclared here (not in a function); did you mean 'a5xx_irq'?
      
      This adds a missing #ifdef.
      
      Fixes: b5f103ab ("drm/msm: gpu: Add A5XX target support")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      0c3eaf1f
    • Rob Clark's avatar
      drm/msm: move submit fence wait out of struct_mutex · 48f243c9
      Rob Clark authored
      Probably a symptom of needing finer grained locking, but if we wait on
      the incoming fence-fd (which could come from a different context) while
      holding struct_mutex, that blocks retire_worker so gpu fences cannot get
      signalled.
      
      This causes a problem if userspace manages to get more than a frame
      ahead, leaving the atomic-commit worker blocked waiting on fences that
      cannot be signaled because submit is blocked waiting for a fence
      signalled from vblank (after the atomic commit which is blocked).
      
      If we start having multiple fence ctxs for the gpu, submit_fence_sync()
      would probably need to move outside of struct_mutex as well.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      48f243c9
    • Rob Clark's avatar
      drm/msm: pm runtime support for iommu · cc692726
      Rob Clark authored
      In particular, attach() and unmap() need pm-runtime get/put to ensure
      iommu clks are enabled.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      cc692726
    • Rob Clark's avatar
      drm/msm: convert to iommu_map_sg · f9000049
      Rob Clark authored
      Significantly simplifies things.  Also iommu_unmap() can unmap an entire
      iova range.
      
      (If backporting to downstream kernel you might need to revert this.  Or
      at least double check older iommu implementation.)
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      f9000049