drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2013 Red Hat
|
|
|
|
* Author: Rob Clark <robdclark@gmail.com>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License version 2 as published by
|
|
|
|
* the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but WITHOUT
|
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
|
|
|
* more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along with
|
|
|
|
* this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __MDP5_KMS_H__
|
|
|
|
#define __MDP5_KMS_H__
|
|
|
|
|
|
|
|
#include "msm_drv.h"
|
|
|
|
#include "msm_kms.h"
|
|
|
|
#include "mdp/mdp_kms.h"
|
2014-11-18 17:49:48 +00:00
|
|
|
#include "mdp5_cfg.h" /* must be included before mdp5.xml.h */
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
#include "mdp5.xml.h"
|
2016-11-01 13:56:51 +00:00
|
|
|
#include "mdp5_pipe.h"
|
2017-03-23 10:27:56 +00:00
|
|
|
#include "mdp5_mixer.h"
|
2017-03-23 10:27:57 +00:00
|
|
|
#include "mdp5_ctl.h"
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
#include "mdp5_smp.h"
|
|
|
|
|
2016-11-04 18:50:08 +00:00
|
|
|
struct mdp5_state;
|
|
|
|
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
struct mdp5_kms {
|
|
|
|
struct mdp_kms base;
|
|
|
|
|
|
|
|
struct drm_device *dev;
|
|
|
|
|
drm/msm/mdp5: Create a separate MDP5 device
In order to have a tree-like device hierarchy between MDSS and its
sub-blocks (MDP5, DSI, HDMI, eDP etc), we need to create a separate
device/driver for MDP5. Currently, MDP5 and MDSS are squashed
together are are tied to the top level platform_device, which is
also the one used to create drm_device.
The mdp5_kms_init code is split into two parts. The part where device
resources are allocated are associated with the MDP5 driver's probe,
the rest is executed later when we initialize modeset.
With this change, unlike MDP4, the MDP5 platform_device isn't tied to
the top level drm_device anymore. The top level drm_device is now
associated with a platform device that corresponds to MDSS wrapper
hardware.
Create mdp5_init/destroy funcs that will be used by the MDP5 driver
probe/remove. Use the HW_VERSION register in the MDP5 register address
space. Both the MDSS and MDP VERSION registers give out identical
version info.
The older mdp5_kms_init code is left as is for now, this would be removed
later when we have all the pieces to support the new device hierarchy.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-05-30 11:06:50 +00:00
|
|
|
struct platform_device *pdev;
|
|
|
|
|
2016-11-01 13:56:51 +00:00
|
|
|
unsigned num_hwpipes;
|
|
|
|
struct mdp5_hw_pipe *hwpipes[SSPP_MAX];
|
|
|
|
|
2017-03-23 10:27:56 +00:00
|
|
|
unsigned num_hwmixers;
|
|
|
|
struct mdp5_hw_mixer *hwmixers[8];
|
|
|
|
|
2017-03-23 10:27:59 +00:00
|
|
|
unsigned num_intfs;
|
|
|
|
struct mdp5_interface *intfs[5];
|
|
|
|
|
2014-11-18 19:28:43 +00:00
|
|
|
struct mdp5_cfg_handler *cfg;
|
2015-09-15 12:41:53 +00:00
|
|
|
uint32_t caps; /* MDP capabilities (MDP_CAP_XXX bits) */
|
|
|
|
|
2016-11-04 18:50:08 +00:00
|
|
|
/**
|
|
|
|
* Global atomic state. Do not access directly, use mdp5_get_state()
|
|
|
|
*/
|
|
|
|
struct mdp5_state *state;
|
|
|
|
struct drm_modeset_lock state_lock;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
|
2014-11-18 19:28:43 +00:00
|
|
|
struct mdp5_smp *smp;
|
|
|
|
struct mdp5_ctl_manager *ctlm;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
|
|
|
|
/* io/register spaces: */
|
2016-06-14 12:54:54 +00:00
|
|
|
void __iomem *mmio;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
|
|
|
|
struct clk *axi_clk;
|
|
|
|
struct clk *ahb_clk;
|
|
|
|
struct clk *core_clk;
|
|
|
|
struct clk *lut_clk;
|
|
|
|
struct clk *vsync_clk;
|
|
|
|
|
2014-11-18 17:49:49 +00:00
|
|
|
/*
|
|
|
|
* lock to protect access to global resources: ie., following register:
|
2016-05-10 05:35:58 +00:00
|
|
|
* - REG_MDP5_DISP_INTF_SEL
|
2014-11-18 17:49:49 +00:00
|
|
|
*/
|
|
|
|
spinlock_t resource_lock;
|
|
|
|
|
2016-06-15 12:34:31 +00:00
|
|
|
bool rpm_enabled;
|
|
|
|
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
struct mdp_irq error_handler;
|
2017-07-03 17:13:57 +00:00
|
|
|
|
|
|
|
int enable_count;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
};
|
|
|
|
#define to_mdp5_kms(x) container_of(x, struct mdp5_kms, base)
|
|
|
|
|
2016-11-04 18:50:08 +00:00
|
|
|
/* Global atomic state for tracking resources that are shared across
|
|
|
|
* multiple kms objects (planes/crtcs/etc).
|
|
|
|
*
|
|
|
|
* For atomic updates which require modifying global state,
|
|
|
|
*/
|
|
|
|
struct mdp5_state {
|
2016-11-01 15:56:54 +00:00
|
|
|
struct mdp5_hw_pipe_state hwpipe;
|
2017-03-23 10:28:02 +00:00
|
|
|
struct mdp5_hw_mixer_state hwmixer;
|
2016-11-01 20:35:32 +00:00
|
|
|
struct mdp5_smp_state smp;
|
2016-11-04 18:50:08 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct mdp5_state *__must_check
|
|
|
|
mdp5_get_state(struct drm_atomic_state *s);
|
|
|
|
|
|
|
|
/* Atomic plane state. Subclasses the base drm_plane_state in order to
|
|
|
|
* track assigned hwpipe and hw specific state.
|
|
|
|
*/
|
2014-11-19 17:31:03 +00:00
|
|
|
struct mdp5_plane_state {
|
|
|
|
struct drm_plane_state base;
|
|
|
|
|
2016-11-01 15:56:54 +00:00
|
|
|
struct mdp5_hw_pipe *hwpipe;
|
drm/msm/mdp5: Assign a 'right hwpipe' to plane state
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: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-03-23 10:28:10 +00:00
|
|
|
struct mdp5_hw_pipe *r_hwpipe; /* right hwpipe */
|
2016-11-01 15:56:54 +00:00
|
|
|
|
2015-06-25 21:37:42 +00:00
|
|
|
/* aligned with property */
|
|
|
|
uint8_t premultiplied;
|
|
|
|
uint8_t zpos;
|
|
|
|
uint8_t alpha;
|
2014-11-19 17:31:03 +00:00
|
|
|
|
2015-06-25 21:37:42 +00:00
|
|
|
/* assigned by crtc blender */
|
2014-11-19 17:31:03 +00:00
|
|
|
enum mdp_mixer_stage_id stage;
|
2014-11-18 17:49:49 +00:00
|
|
|
};
|
2014-11-19 17:31:03 +00:00
|
|
|
#define to_mdp5_plane_state(x) \
|
|
|
|
container_of(x, struct mdp5_plane_state, base)
|
2014-11-18 17:49:49 +00:00
|
|
|
|
2017-03-23 10:28:01 +00:00
|
|
|
struct mdp5_pipeline {
|
|
|
|
struct mdp5_interface *intf;
|
|
|
|
struct mdp5_hw_mixer *mixer;
|
drm/msm/mdp5: Add optional 'right' Layer Mixer in CRTC state
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: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-03-23 10:28:08 +00:00
|
|
|
struct mdp5_hw_mixer *r_mixer; /* right mixer */
|
2017-03-23 10:28:01 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct mdp5_crtc_state {
|
|
|
|
struct drm_crtc_state base;
|
|
|
|
|
|
|
|
struct mdp5_ctl *ctl;
|
|
|
|
struct mdp5_pipeline pipeline;
|
2017-03-23 10:28:04 +00:00
|
|
|
|
|
|
|
/* these are derivatives of intf/mixer state in mdp5_pipeline */
|
|
|
|
u32 vblank_irqmask;
|
|
|
|
u32 err_irqmask;
|
|
|
|
u32 pp_done_irqmask;
|
|
|
|
|
|
|
|
bool cmd_mode;
|
2017-03-23 10:28:01 +00:00
|
|
|
};
|
|
|
|
#define to_mdp5_crtc_state(x) \
|
|
|
|
container_of(x, struct mdp5_crtc_state, base)
|
|
|
|
|
2015-03-13 19:49:32 +00:00
|
|
|
enum mdp5_intf_mode {
|
|
|
|
MDP5_INTF_MODE_NONE = 0,
|
|
|
|
|
|
|
|
/* Modes used for DSI interface (INTF_DSI type): */
|
|
|
|
MDP5_INTF_DSI_MODE_VIDEO,
|
|
|
|
MDP5_INTF_DSI_MODE_COMMAND,
|
|
|
|
|
|
|
|
/* Modes used for WB interface (INTF_WB type): */
|
|
|
|
MDP5_INTF_WB_MODE_BLOCK,
|
|
|
|
MDP5_INTF_WB_MODE_LINE,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct mdp5_interface {
|
2017-03-23 10:27:59 +00:00
|
|
|
int idx;
|
2015-03-13 19:49:32 +00:00
|
|
|
int num; /* display interface number */
|
|
|
|
enum mdp5_intf_type type;
|
|
|
|
enum mdp5_intf_mode mode;
|
|
|
|
};
|
|
|
|
|
2017-01-16 05:55:38 +00:00
|
|
|
struct mdp5_encoder {
|
|
|
|
struct drm_encoder base;
|
|
|
|
spinlock_t intf_lock; /* protect REG_MDP5_INTF_* registers */
|
|
|
|
bool enabled;
|
|
|
|
uint32_t bsc;
|
|
|
|
|
2017-03-23 10:27:59 +00:00
|
|
|
struct mdp5_interface *intf;
|
2017-01-16 05:55:38 +00:00
|
|
|
struct mdp5_ctl *ctl;
|
|
|
|
};
|
|
|
|
#define to_mdp5_encoder(x) container_of(x, struct mdp5_encoder, base)
|
|
|
|
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
static inline void mdp5_write(struct mdp5_kms *mdp5_kms, u32 reg, u32 data)
|
|
|
|
{
|
2017-07-03 17:13:57 +00:00
|
|
|
WARN_ON(mdp5_kms->enable_count <= 0);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
msm_writel(data, mdp5_kms->mmio + reg);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u32 mdp5_read(struct mdp5_kms *mdp5_kms, u32 reg)
|
|
|
|
{
|
2017-07-03 17:13:57 +00:00
|
|
|
WARN_ON(mdp5_kms->enable_count <= 0);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
return msm_readl(mdp5_kms->mmio + reg);
|
|
|
|
}
|
|
|
|
|
2016-11-05 15:08:11 +00:00
|
|
|
static inline const char *stage2name(enum mdp_mixer_stage_id stage)
|
|
|
|
{
|
|
|
|
static const char *names[] = {
|
|
|
|
#define NAME(n) [n] = #n
|
|
|
|
NAME(STAGE_UNUSED), NAME(STAGE_BASE),
|
|
|
|
NAME(STAGE0), NAME(STAGE1), NAME(STAGE2),
|
|
|
|
NAME(STAGE3), NAME(STAGE4), NAME(STAGE6),
|
|
|
|
#undef NAME
|
|
|
|
};
|
|
|
|
return names[stage];
|
|
|
|
}
|
|
|
|
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
static inline const char *pipe2name(enum mdp5_pipe pipe)
|
|
|
|
{
|
|
|
|
static const char *names[] = {
|
|
|
|
#define NAME(n) [SSPP_ ## n] = #n
|
|
|
|
NAME(VIG0), NAME(VIG1), NAME(VIG2),
|
|
|
|
NAME(RGB0), NAME(RGB1), NAME(RGB2),
|
|
|
|
NAME(DMA0), NAME(DMA1),
|
2014-07-07 14:34:01 +00:00
|
|
|
NAME(VIG3), NAME(RGB3),
|
2017-01-16 06:27:04 +00:00
|
|
|
NAME(CURSOR0), NAME(CURSOR1),
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
#undef NAME
|
|
|
|
};
|
|
|
|
return names[pipe];
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int pipe2nclients(enum mdp5_pipe pipe)
|
|
|
|
{
|
|
|
|
switch (pipe) {
|
|
|
|
case SSPP_RGB0:
|
|
|
|
case SSPP_RGB1:
|
|
|
|
case SSPP_RGB2:
|
2014-07-07 14:34:01 +00:00
|
|
|
case SSPP_RGB3:
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
return 1;
|
|
|
|
default:
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-03-13 19:49:32 +00:00
|
|
|
static inline uint32_t intf2err(int intf_num)
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
{
|
2015-03-13 19:49:32 +00:00
|
|
|
switch (intf_num) {
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
case 0: return MDP5_IRQ_INTF0_UNDER_RUN;
|
|
|
|
case 1: return MDP5_IRQ_INTF1_UNDER_RUN;
|
|
|
|
case 2: return MDP5_IRQ_INTF2_UNDER_RUN;
|
|
|
|
case 3: return MDP5_IRQ_INTF3_UNDER_RUN;
|
|
|
|
default: return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-03-23 10:27:58 +00:00
|
|
|
static inline uint32_t intf2vblank(struct mdp5_hw_mixer *mixer,
|
|
|
|
struct mdp5_interface *intf)
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
{
|
2015-03-13 19:49:32 +00:00
|
|
|
/*
|
|
|
|
* In case of DSI Command Mode, the Ping Pong's read pointer IRQ
|
|
|
|
* acts as a Vblank signal. The Ping Pong buffer used is bound to
|
|
|
|
* layer mixer.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if ((intf->type == INTF_DSI) &&
|
|
|
|
(intf->mode == MDP5_INTF_DSI_MODE_COMMAND))
|
2017-03-23 10:27:58 +00:00
|
|
|
return MDP5_IRQ_PING_PONG_0_RD_PTR << mixer->pp;
|
2015-03-13 19:49:32 +00:00
|
|
|
|
|
|
|
if (intf->type == INTF_WB)
|
|
|
|
return MDP5_IRQ_WB_2_DONE;
|
|
|
|
|
|
|
|
switch (intf->num) {
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
case 0: return MDP5_IRQ_INTF0_VSYNC;
|
|
|
|
case 1: return MDP5_IRQ_INTF1_VSYNC;
|
|
|
|
case 2: return MDP5_IRQ_INTF2_VSYNC;
|
|
|
|
case 3: return MDP5_IRQ_INTF3_VSYNC;
|
|
|
|
default: return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-03-23 10:27:58 +00:00
|
|
|
static inline uint32_t lm2ppdone(struct mdp5_hw_mixer *mixer)
|
2015-03-26 23:25:17 +00:00
|
|
|
{
|
2017-03-23 10:27:58 +00:00
|
|
|
return MDP5_IRQ_PING_PONG_0_DONE << mixer->pp;
|
2015-03-26 23:25:17 +00:00
|
|
|
}
|
|
|
|
|
2015-08-05 19:33:29 +00:00
|
|
|
void mdp5_set_irqmask(struct mdp_kms *mdp_kms, uint32_t irqmask,
|
|
|
|
uint32_t old_irqmask);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
void mdp5_irq_preinstall(struct msm_kms *kms);
|
|
|
|
int mdp5_irq_postinstall(struct msm_kms *kms);
|
|
|
|
void mdp5_irq_uninstall(struct msm_kms *kms);
|
|
|
|
irqreturn_t mdp5_irq(struct msm_kms *kms);
|
|
|
|
int mdp5_enable_vblank(struct msm_kms *kms, struct drm_crtc *crtc);
|
|
|
|
void mdp5_disable_vblank(struct msm_kms *kms, struct drm_crtc *crtc);
|
drm/msm/mdp5: use irqdomains
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: Rob Clark <robdclark@gmail.com>
2014-11-17 20:28:07 +00:00
|
|
|
int mdp5_irq_domain_init(struct mdp5_kms *mdp5_kms);
|
|
|
|
void mdp5_irq_domain_fini(struct mdp5_kms *mdp5_kms);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
|
2014-11-18 17:49:49 +00:00
|
|
|
uint32_t mdp5_plane_get_flush(struct drm_plane *plane);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane);
|
2017-03-23 10:28:11 +00:00
|
|
|
enum mdp5_pipe mdp5_plane_right_pipe(struct drm_plane *plane);
|
2017-01-16 06:27:04 +00:00
|
|
|
struct drm_plane *mdp5_plane_init(struct drm_device *dev,
|
|
|
|
enum drm_plane_type type);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
|
2016-12-16 06:29:57 +00:00
|
|
|
struct mdp5_ctl *mdp5_crtc_get_ctl(struct drm_crtc *crtc);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
uint32_t mdp5_crtc_vblank(struct drm_crtc *crtc);
|
|
|
|
|
2017-03-23 10:27:57 +00:00
|
|
|
struct mdp5_hw_mixer *mdp5_crtc_get_mixer(struct drm_crtc *crtc);
|
2017-03-23 10:28:06 +00:00
|
|
|
struct mdp5_pipeline *mdp5_crtc_get_pipeline(struct drm_crtc *crtc);
|
|
|
|
void mdp5_crtc_set_pipeline(struct drm_crtc *crtc);
|
2015-04-28 23:35:37 +00:00
|
|
|
void mdp5_crtc_wait_for_commit_done(struct drm_crtc *crtc);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
struct drm_crtc *mdp5_crtc_init(struct drm_device *dev,
|
2017-01-16 06:27:04 +00:00
|
|
|
struct drm_plane *plane,
|
|
|
|
struct drm_plane *cursor_plane, int id);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
|
2015-03-13 19:49:32 +00:00
|
|
|
struct drm_encoder *mdp5_encoder_init(struct drm_device *dev,
|
2015-06-26 20:03:25 +00:00
|
|
|
struct mdp5_interface *intf, struct mdp5_ctl *ctl);
|
2016-12-06 03:51:21 +00:00
|
|
|
int mdp5_vid_encoder_set_split_display(struct drm_encoder *encoder,
|
|
|
|
struct drm_encoder *slave_encoder);
|
2016-12-05 09:54:53 +00:00
|
|
|
void mdp5_encoder_set_intf_mode(struct drm_encoder *encoder, bool cmd_mode);
|
2015-10-26 09:13:57 +00:00
|
|
|
int mdp5_encoder_get_linecount(struct drm_encoder *encoder);
|
|
|
|
u32 mdp5_encoder_get_framecount(struct drm_encoder *encoder);
|
2015-03-26 23:25:17 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_DRM_MSM_DSI
|
2017-01-16 05:55:38 +00:00
|
|
|
void mdp5_cmd_encoder_mode_set(struct drm_encoder *encoder,
|
|
|
|
struct drm_display_mode *mode,
|
|
|
|
struct drm_display_mode *adjusted_mode);
|
|
|
|
void mdp5_cmd_encoder_disable(struct drm_encoder *encoder);
|
|
|
|
void mdp5_cmd_encoder_enable(struct drm_encoder *encoder);
|
2015-03-26 23:25:17 +00:00
|
|
|
int mdp5_cmd_encoder_set_split_display(struct drm_encoder *encoder,
|
2017-01-16 05:55:38 +00:00
|
|
|
struct drm_encoder *slave_encoder);
|
2015-03-26 23:25:17 +00:00
|
|
|
#else
|
2017-01-16 05:55:38 +00:00
|
|
|
static inline void mdp5_cmd_encoder_mode_set(struct drm_encoder *encoder,
|
|
|
|
struct drm_display_mode *mode,
|
|
|
|
struct drm_display_mode *adjusted_mode)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
static inline void mdp5_cmd_encoder_disable(struct drm_encoder *encoder)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
static inline void mdp5_cmd_encoder_enable(struct drm_encoder *encoder)
|
2015-03-26 23:25:17 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
static inline int mdp5_cmd_encoder_set_split_display(
|
|
|
|
struct drm_encoder *encoder, struct drm_encoder *slave_encoder)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
#endif
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
|
|
|
|
|
|
|
#endif /* __MDP5_KMS_H__ */
|