On 11/7/2016 8:18 PM, Rob Clark wrote:
On Mon, Nov 7, 2016 at 5:38 AM, Archit Taneja <architt@xxxxxxxxxxxxxx> wrote:
On 11/05/2016 09:55 PM, Rob Clark wrote:
Split out the hardware pipe specifics from mdp5_plane. To start, the hw
pipes are statically assigned to planes, but next step is to assign the
hw pipes during plane->atomic_check() based on requested caps (scaling,
YUV, etc). And then hw pipe re-assignment if required if required SMP
blocks changes.
Signed-off-by: Rob Clark <robdclark@xxxxxxxxx>
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 126
+++++++++++++++++++-----------
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 7 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c | 43 ++++++++++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.h | 39 +++++++++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 66 +++++++---------
6 files changed, 197 insertions(+), 85 deletions(-)
create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c
create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index fb5be3e..90f66c4 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -37,6 +37,7 @@ msm-y := \
mdp/mdp5/mdp5_irq.o \
mdp/mdp5/mdp5_mdss.o \
mdp/mdp5/mdp5_kms.o \
+ mdp/mdp5/mdp5_pipe.o \
mdp/mdp5/mdp5_plane.o \
mdp/mdp5/mdp5_smp.o \
msm_atomic.o \
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index f1288c7..d3d45ed 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -119,6 +119,10 @@ static void mdp5_kms_destroy(struct msm_kms *kms)
{
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
struct msm_gem_address_space *aspace = mdp5_kms->aspace;
+ int i;
+
+ for (i = 0; i < mdp5_kms->num_hwpipes; i++)
+ mdp5_pipe_destroy(mdp5_kms->hwpipes[i]);
if (aspace) {
aspace->mmu->funcs->detach(aspace->mmu,
@@ -323,15 +327,6 @@ static int modeset_init_intf(struct mdp5_kms
*mdp5_kms, int intf_num)
static int modeset_init(struct mdp5_kms *mdp5_kms)
{
- static const enum mdp5_pipe rgb_planes[] = {
- SSPP_RGB0, SSPP_RGB1, SSPP_RGB2, SSPP_RGB3,
- };
- static const enum mdp5_pipe vig_planes[] = {
- SSPP_VIG0, SSPP_VIG1, SSPP_VIG2, SSPP_VIG3,
- };
- static const enum mdp5_pipe dma_planes[] = {
- SSPP_DMA0, SSPP_DMA1,
- };
struct drm_device *dev = mdp5_kms->dev;
struct msm_drm_private *priv = dev->dev_private;
const struct mdp5_cfg_hw *hw_cfg;
@@ -339,58 +334,34 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
- /* construct CRTCs and their private planes: */
- for (i = 0; i < hw_cfg->pipe_rgb.count; i++) {
+ /* Construct planes equaling the number of hw pipes, and CRTCs
+ * for the N layer-mixers (LM). The first N planes become primary
+ * planes for the CRTCs, with the remainder as overlay planes:
+ */
Jfyi, we might need to change this a bit in the future. It'll be better to
get the max number of displays connected on our platform via parsing DT,
etc, and calculate CRTCs based on that, and not number of layermixers. Maybe
add a couple for writeback too. This way, we get the right number of
CRTCs, and we don't rely on #LMs, since we can have 2 per crtc
in the future.
I *guess* when we get to that stage, we'll dynamically assign LM's
too, in a similar way as hwpipe. And I suppose we could also put a
cap on # of crtc's based on # of encoders?
Yeah. Currently, we end up creating 2 encoders for each DSI instance,
i.e, 1 for command mode, and another for video mode. Only one can be
used at a time. If we adjust for that, then I guess # of crtcs should
equal to # of encoders.
Archit
BR,
-R
Reviewed-by: Archit Taneja <architt@xxxxxxxxxxxxxx>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
