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"
|
2014-11-18 17:49:49 +00:00
|
|
|
#include "mdp5_ctl.h"
|
2016-11-01 13:56:51 +00:00
|
|
|
#include "mdp5_pipe.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];
|
|
|
|
|
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
|
|
|
|
|
|
|
/* mapper-id used to request GEM buffer mapped for scanout: */
|
|
|
|
int id;
|
2016-09-28 23:58:32 +00:00
|
|
|
struct msm_gem_address_space *aspace;
|
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;
|
|
|
|
};
|
|
|
|
#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;
|
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;
|
|
|
|
|
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
|
|
|
|
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 {
|
|
|
|
int num; /* display interface number */
|
|
|
|
enum mdp5_intf_type type;
|
|
|
|
enum mdp5_intf_mode mode;
|
|
|
|
};
|
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
msm_writel(data, mdp5_kms->mmio + reg);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u32 mdp5_read(struct mdp5_kms *mdp5_kms, u32 reg)
|
|
|
|
{
|
|
|
|
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),
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-03-26 23:25:17 +00:00
|
|
|
#define GET_PING_PONG_ID(layer_mixer) ((layer_mixer == 5) ? 3 : layer_mixer)
|
2015-03-13 19:49:32 +00:00
|
|
|
static inline uint32_t intf2vblank(int lm, 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))
|
|
|
|
return MDP5_IRQ_PING_PONG_0_RD_PTR << GET_PING_PONG_ID(lm);
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-03-26 23:25:17 +00:00
|
|
|
static inline uint32_t lm2ppdone(int lm)
|
|
|
|
{
|
|
|
|
return MDP5_IRQ_PING_PONG_0_DONE << GET_PING_PONG_ID(lm);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
int mdp5_disable(struct mdp5_kms *mdp5_kms);
|
|
|
|
int mdp5_enable(struct mdp5_kms *mdp5_kms);
|
|
|
|
|
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);
|
2016-11-01 15:56:54 +00:00
|
|
|
struct drm_plane *mdp5_plane_init(struct drm_device *dev, bool primary);
|
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);
|
|
|
|
|
2014-11-18 17:49:49 +00:00
|
|
|
int mdp5_crtc_get_lm(struct drm_crtc *crtc);
|
2015-06-26 20:03:25 +00:00
|
|
|
void mdp5_crtc_set_pipeline(struct drm_crtc *crtc,
|
|
|
|
struct mdp5_interface *intf, struct mdp5_ctl *ctl);
|
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,
|
|
|
|
struct drm_plane *plane, int id);
|
|
|
|
|
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);
|
2015-03-26 23:25:17 +00:00
|
|
|
int mdp5_encoder_set_split_display(struct drm_encoder *encoder,
|
|
|
|
struct drm_encoder *slave_encoder);
|
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
|
|
|
|
struct drm_encoder *mdp5_cmd_encoder_init(struct drm_device *dev,
|
2015-06-26 20:03:25 +00:00
|
|
|
struct mdp5_interface *intf, struct mdp5_ctl *ctl);
|
2015-03-26 23:25:17 +00:00
|
|
|
int mdp5_cmd_encoder_set_split_display(struct drm_encoder *encoder,
|
|
|
|
struct drm_encoder *slave_encoder);
|
|
|
|
#else
|
2015-06-26 20:03:25 +00:00
|
|
|
static inline struct drm_encoder *mdp5_cmd_encoder_init(struct drm_device *dev,
|
|
|
|
struct mdp5_interface *intf, struct mdp5_ctl *ctl)
|
2015-03-26 23:25:17 +00:00
|
|
|
{
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
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__ */
|