Files
linux/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h

113 lines
2.6 KiB
C
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0-only */
drm/msm/dpu: Add CRC support for DPU Add CRC support to DPU, which is currently not supported by this driver. Only supports CRC for CRTC for now, but will extend support to other blocks later on. Changes in v2: - Added kfree() calls for return paths in dpu_crtc_get_crc() - Propogated error code for dpu_crtc_get_crc() - Renamed skip_count - Removed dpu_crtc_is_valid_crc_source() - Removed wait for commit in dpu_crtc_set_crc_source() - Moved crc_source from struct dpu_crtc to struct dpu_crtc_state - Moved CRC register constants from dpu_hw_util.h to dpu_hw_lm.c Validated with IGT kms_pipe_crc_basic, and kms_cursor_crc Test: kms_pipe_crc_basic Subtests Passed: - bad-source - read-crc-pipe-A - read-crc-pipe-A-frame-sequence - nonblocking-crc-pipe-A - nonblocking-crc-pipe-A-frame-sequence - disable-crc-after-crtc-pipe-A[1] - compare-crc-sanitycheck-pipe-A[1] Rest skipped Test: kms_cursor_crc Subtests Passed: - pipe-A-cursor-size-change - pipe-A-cursor-alpha-opaque - pipe-A-cursor-alpha-transparent Subtests Failed: - pipe-A-cursor-dpms - pipe-A-cursor-*-onscreen - pipe-A-cursor-*-offscreen Rest skipped Tested on Qualcomm RB3 (debian, sdm845), Qualcomm RB5 (debian, qrb5165) Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jessica Zhang <jesszhan@codeaurora.org> [1] Skipped on RB5 due to issue related to DPMS. Planning to upload a fix for this in the future. Link: https://lore.kernel.org/r/20211019224822.25940-1-jesszhan@codeaurora.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-19 15:48:22 -07:00
/*
* Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
drm/msm: Add SDM845 DPU support 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: Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Chandan Uddaraju <chandanu@codeaurora.org> Signed-off-by: Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rajesh Yadav <ryadav@codeaurora.org> Signed-off-by: Sravanthi Kollukuduru <skolluku@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> [robclark minor rebase] Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-06-27 15:26:09 -04:00
*/
#ifndef _DPU_HW_LM_H
#define _DPU_HW_LM_H
#include "dpu_hw_mdss.h"
#include "dpu_hw_util.h"
struct dpu_hw_mixer;
struct dpu_hw_mixer_cfg {
u32 out_width;
u32 out_height;
bool right_mixer;
int flags;
};
struct dpu_hw_color3_cfg {
u8 keep_fg[DPU_STAGE_MAX];
};
/**
*
* struct dpu_hw_lm_ops : Interface to the mixer Hw driver functions
* Assumption is these functions will be called after clocks are enabled
*/
struct dpu_hw_lm_ops {
/*
* Sets up mixer output width and height
* and border color if enabled
*/
void (*setup_mixer_out)(struct dpu_hw_mixer *ctx,
struct dpu_hw_mixer_cfg *cfg);
/*
* Alpha blending configuration
* for the specified stage
*/
void (*setup_blend_config)(struct dpu_hw_mixer *ctx, uint32_t stage,
uint32_t fg_alpha, uint32_t bg_alpha, uint32_t blend_op);
/*
* Alpha color component selection from either fg or bg
*/
void (*setup_alpha_out)(struct dpu_hw_mixer *ctx, uint32_t mixer_op);
/**
* setup_border_color : enable/disable border color
*/
void (*setup_border_color)(struct dpu_hw_mixer *ctx,
struct dpu_mdss_color *color,
u8 border_en);
drm/msm/dpu: Add CRC support for DPU Add CRC support to DPU, which is currently not supported by this driver. Only supports CRC for CRTC for now, but will extend support to other blocks later on. Changes in v2: - Added kfree() calls for return paths in dpu_crtc_get_crc() - Propogated error code for dpu_crtc_get_crc() - Renamed skip_count - Removed dpu_crtc_is_valid_crc_source() - Removed wait for commit in dpu_crtc_set_crc_source() - Moved crc_source from struct dpu_crtc to struct dpu_crtc_state - Moved CRC register constants from dpu_hw_util.h to dpu_hw_lm.c Validated with IGT kms_pipe_crc_basic, and kms_cursor_crc Test: kms_pipe_crc_basic Subtests Passed: - bad-source - read-crc-pipe-A - read-crc-pipe-A-frame-sequence - nonblocking-crc-pipe-A - nonblocking-crc-pipe-A-frame-sequence - disable-crc-after-crtc-pipe-A[1] - compare-crc-sanitycheck-pipe-A[1] Rest skipped Test: kms_cursor_crc Subtests Passed: - pipe-A-cursor-size-change - pipe-A-cursor-alpha-opaque - pipe-A-cursor-alpha-transparent Subtests Failed: - pipe-A-cursor-dpms - pipe-A-cursor-*-onscreen - pipe-A-cursor-*-offscreen Rest skipped Tested on Qualcomm RB3 (debian, sdm845), Qualcomm RB5 (debian, qrb5165) Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jessica Zhang <jesszhan@codeaurora.org> [1] Skipped on RB5 due to issue related to DPMS. Planning to upload a fix for this in the future. Link: https://lore.kernel.org/r/20211019224822.25940-1-jesszhan@codeaurora.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-19 15:48:22 -07:00
/**
* setup_misr: Enable/disable MISR
*/
void (*setup_misr)(struct dpu_hw_mixer *ctx, bool enable, u32 frame_count);
/**
* collect_misr: Read MISR signature
*/
int (*collect_misr)(struct dpu_hw_mixer *ctx, u32 *misr_value);
drm/msm: Add SDM845 DPU support 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: Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Chandan Uddaraju <chandanu@codeaurora.org> Signed-off-by: Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rajesh Yadav <ryadav@codeaurora.org> Signed-off-by: Sravanthi Kollukuduru <skolluku@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> [robclark minor rebase] Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-06-27 15:26:09 -04:00
};
struct dpu_hw_mixer {
struct dpu_hw_blk base;
struct dpu_hw_blk_reg_map hw;
/* lm */
enum dpu_lm idx;
const struct dpu_lm_cfg *cap;
const struct dpu_mdp_cfg *mdp;
const struct dpu_ctl_cfg *ctl;
/* ops */
struct dpu_hw_lm_ops ops;
/* store mixer info specific to display */
struct dpu_hw_mixer_cfg cfg;
};
/**
* to_dpu_hw_mixer - convert base object dpu_hw_base to container
* @hw: Pointer to base hardware block
* return: Pointer to hardware block container
*/
static inline struct dpu_hw_mixer *to_dpu_hw_mixer(struct dpu_hw_blk *hw)
{
return container_of(hw, struct dpu_hw_mixer, base);
}
/**
* dpu_hw_lm_init(): Initializes the mixer hw driver object.
* should be called once before accessing every mixer.
* @idx: mixer index for which driver object is required
* @addr: mapped register io address of MDP
* @m : pointer to mdss catalog data
*/
struct dpu_hw_mixer *dpu_hw_lm_init(enum dpu_lm idx,
void __iomem *addr,
const struct dpu_mdss_cfg *m);
drm/msm: Add SDM845 DPU support 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: Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Chandan Uddaraju <chandanu@codeaurora.org> Signed-off-by: Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rajesh Yadav <ryadav@codeaurora.org> Signed-off-by: Sravanthi Kollukuduru <skolluku@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> [robclark minor rebase] Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-06-27 15:26:09 -04:00
/**
* dpu_hw_lm_destroy(): Destroys layer mixer driver context
* @lm: Pointer to LM driver context
*/
void dpu_hw_lm_destroy(struct dpu_hw_mixer *lm);
#endif /*_DPU_HW_LM_H */