1. 20 4月, 2019 2 次提交
  2. 01 2月, 2019 4 次提交
  3. 29 1月, 2019 2 次提交
  4. 25 1月, 2019 2 次提交
  5. 24 1月, 2019 1 次提交
  6. 12 12月, 2018 7 次提交
  7. 04 10月, 2018 1 次提交
    • S
      drm/msm: dpu: Allow planes to extend past active display · 96fc56a7
      Sean Paul 提交于
      The atomic_check is a bit too aggressive with respect to planes which
      leave the active area. This caused a bunch of log spew when the cursor
      got to the edge of the screen and stopped it from going all the way.
      
      This patch removes the conservative bounds checks from atomic and clips
      the dst rect such that we properly display planes which go off the
      screen.
      
      Changes in v2:
      - Apply the clip to src as well (taking into account scaling)
      Changes in v3:
      - Use drm_atomic_helper_check_plane_state() to clip src/dst
      
      Cc: Sravanthi Kollukuduru <skolluku@codeaurora.org>
      Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NJeykumar Sankaran <jsanka@codeaurora.org>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      96fc56a7
  8. 11 8月, 2018 1 次提交
  9. 03 8月, 2018 1 次提交
  10. 26 7月, 2018 3 次提交
    • J
      drm/msm: Add SDM845 DPU support · 25fdd593
      Jeykumar Sankaran 提交于
      SDM845 SoC includes the Mobile Display Sub System (MDSS) which is a
      top level wrapper consisting of Display Processing Unit (DPU) and
      display peripheral modules such as Display Serial Interface (DSI)
      and DisplayPort (DP).
      
      MDSS functions essentially as a back-end composition engine. It blends
      video and graphic images stored in the frame buffers and scans out the
      composed image to a display sink (over DSI/DP).
      
      The following diagram represents hardware blocks for a simple pipeline
      (two planes are present on a given crtc which is connected to a DSI
      connector):
      
             MDSS
            +---------------------------------+
            | +-----------------------------+ |
            | | DPU                         | |
            | |  +--------+  +--------+     | |
            | |  |  SSPP  |  |  SSPP  |     | |
            | |  +----+---+  +----+---+     | |
            | |       |           |         | |
            | |  +----v-----------v---+     | |
            | |  |  Layer Mixer (LM)  |     | |
            | |  +--------------------+     | |
            | |  +--------------------+     | |
            | |  |    PingPong (PP)   |     | |
            | |  +--------------------+     | |
            | |  +--------------------+     | |
            | |  |  INTERFACE (VIDEO) |     | |
            | |  +---+----------------+     | |
            | +------|----------------------+ |
            |        |                        |
            | +------|---------------------+  |
            | |      | DISPLAY PERIPHERALS |  |
            | |  +---v-+      +-----+      |  |
            | |  | DSI |      |  DP |      |  |
            | |  +-----+      +-----+      |  |
            | +----------------------------+  |
            +---------------------------------+
      
      The number of DPU sub-blocks (i.e. SSPPs, LMs, PP blocks and INTFs)
      depends on SoC capabilities.
      
      Overview of DPU sub-blocks:
      ---------------------------
      * Source Surface Processor (SSPP):
       Refers to any of hardware pipes like ViG, DMA etc. Only ViG pipes are
       capable of performing format conversion, scaling and quality improvement
       for source surfaces.
      
      * Layer Mixer (LM):
       Blend source surfaces together (in requested zorder)
      
      * PingPong (PP):
       This block controls frame done interrupt output, EOL and EOF generation,
       overflow/underflow control.
      
      * Display interface (INTF):
       Timing generator and interface connecting the display peripherals.
      
      DRM components mapping to DPU architecture:
      ------------------------------------------
      PLANEs maps to SSPPs
      CRTC maps to LMs
      Encoder maps to PPs, INTFs
      
      Data flow setup:
      ---------------
      MDSS hardware can support various data flows (e.g.):
        - Dual pipe: Output from two LMs combined to single display.
        - Split display: Output from two LMs connected to two separate
                         interfaces.
      
      The hardware capabilities determine the number of concurrent data paths
      possible. Any control path (i.e. pipeline w/i DPU) can be routed to any
      of the hardware data paths. A given control path can be triggered,
      flushed and controlled independently.
      
      Changes in v3:
      - Move msm_media_info.h from uapi to dpu/ subdir
      - Remove preclose callback dpu (it's handled in core)
      - Fix kbuild warnings with parent_ops
      - Remove unused functions from dpu_core_irq
      - Rename mdss_phys to mdss
      - Rename mdp_phys address space to mdp
      - Drop _phys from vbif and regdma binding names
      Signed-off-by: NAbhinav Kumar <abhinavk@codeaurora.org>
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NChandan Uddaraju <chandanu@codeaurora.org>
      Signed-off-by: NJeykumar Sankaran <jsanka@codeaurora.org>
      Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: NRajesh Yadav <ryadav@codeaurora.org>
      Signed-off-by: NSravanthi Kollukuduru <skolluku@codeaurora.org>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      [robclark minor rebase]
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      25fdd593
    • J
      drm/msm: #define MAX_<OBJECT> in msm_drv.h · 7305a0ce
      Jeykumar Sankaran 提交于
      dpu uses these elsewhere in the driver (in addition to increasing
      MAX_PLANES, that'll come later), so pull them out into #define.
      
      Changes in v3:
      - None
      Signed-off-by: NJeykumar Sankaran <jsanka@codeaurora.org>
      [seanpaul pulled this out of the dpu megapatch]
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      7305a0ce
    • S
      drm/msm: Clean up dangling atomic_wq · 74312fc7
      Sean Paul 提交于
      I missed this during the atomic conversion
      
      Changes in v3:
      - None
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      74312fc7
  11. 25 7月, 2018 1 次提交
  12. 05 6月, 2018 3 次提交
  13. 19 3月, 2018 1 次提交
  14. 14 12月, 2017 1 次提交
    • A
      drm/msm: fix msm_rd_dump_submit prototype · e6756d7c
      Arnd Bergmann 提交于
      The prototype of msm_rd_dump_submit() has recently changed. However,
      we have two declarations of this functions, and the other one
      remains the old version, leading to this:
      
      drivers/gpu/drm/msm/msm_gpu.c: In function 'recover_worker':
      drivers/gpu/drm/msm/msm_gpu.c:295:23: error: passing argument 1 of 'msm_rd_dump_submit' from incompatible pointer type [-Werror=incompatible-pointer-types]
      
      This changes the second one to match the first again.
      
      Fixes: 2165e2b9 ("drm/msm: split rd debugfs file")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      e6756d7c
  15. 29 10月, 2017 4 次提交
  16. 28 10月, 2017 4 次提交
    • J
      drm/msm: Removed unused struct_mutex_task · 3ceaa141
      Jordan Crouse 提交于
      Recent changes to locking have rendered struct_mutex_task
      unused.
      
      Unused since 0e08270a.
      Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      3ceaa141
    • J
      drm/msm: Implement preemption for A5XX targets · b1fc2839
      Jordan Crouse 提交于
      Implement preemption for A5XX targets - this allows multiple
      ringbuffers for different priorities with automatic preemption
      of a lower priority ringbuffer if a higher one is ready.
      Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      b1fc2839
    • J
      drm/msm: Support multiple ringbuffers · f97decac
      Jordan Crouse 提交于
      Add the infrastructure to support the idea of multiple ringbuffers.
      Assign each ringbuffer an id and use that as an index for the various
      ring specific operations.
      
      The biggest delta is to support legacy fences. Each fence gets its own
      sequence number but the legacy functions expect to use a unique integer.
      To handle this we return a unique identifier for each submission but
      map it to a specific ring/sequence under the covers. Newer users use
      a dma_fence pointer anyway so they don't care about the actual sequence
      ID or ring.
      
      The actual mechanics for multiple ringbuffers are very target specific
      so this code just allows for the possibility but still only defines
      one ringbuffer for each target family.
      Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      f97decac
    • J
      drm/msm: Add per-instance submit queues · f7de1545
      Jordan Crouse 提交于
      Currently the behavior of a command stream is provided by the user
      application during submission and the application is expected to internally
      maintain the settings for each 'context' or 'rendering queue' and specify
      the correct ones.
      
      This works okay for simple cases but as applications become more
      complex we will want to set context specific flags and do various
      permission checks to allow certain contexts to enable additional
      privileges.
      
      Add kernel-side submit queues to be analogous to 'contexts' or
      'rendering queues' on the application side. Each file descriptor
      instance will maintain its own list of queues. Queues cannot be
      shared between file descriptors.
      
      For backwards compatibility context id '0' is defined as a default
      context specifying no priority and no special flags. This is
      intended to be the usual configuration for 99% of applications so
      that a garden variety application can function correctly without
      creating a queue. Only those applications requiring the specific
      benefit of different queues need create one.
      Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      f7de1545
  17. 23 8月, 2017 2 次提交