msm8x74v1 has different MDP5 version (v1.0) from msm8x74v2 (v1.2).
Add a separate config data to support msm8x74v1.
Signed-off-by: NJilai Wang <jilaiw@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

MDP planes can be implemented using different type of HW pipes,
RGB/VIG/DMA pipes for MDP5 and RGB/VG/DMA pipes for MDP4. Each type
of pipe has different HW capabilities such as scaling, color space
conversion, decimation... Add a variable in plane data structure
to specify the difference of each plane which comes from mdp5_cfg data
and use it to differenciate the plane operation.
V1: Initial change
V2: Fix a typo in mdp4_kms.h
Signed-off-by: NJilai Wang <jilaiw@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The maximum output width of one pipeline depends on the LayerMixer's
capability. It may be different on each target. Also, MDP5 doesn't
have vertical limitation in one frame, as long as the pixel clock
can be supported.

This change obtains the maximum LM resolution from configuration
table and treat it as the whole pipe's limitation for MDP5. The size
limit on MDP4 is not changed.
Signed-off-by: NHai Li <hali@codeaurora.org>

This change adds the MDP and HDMI support for msm8x94.
Note that HDMI PHY registers are not being accessed anymore from
the driver.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
[rename compatible s/8x94/8994/ since preference is to not trust the
marketing folks who invent chip #'s but instead name things after the
lead chip.. we should rename some 80XY to 89XY to standardize on the
lead chip but leave that for another patch.  Also, update dt bindings
doc]
Signed-off-by: NRob Clark <robdclark@gmail.com>

The current iteration in get_dsi_id_from_intf() is wrong:
instead of iterating until hw_cfg->intf.count, we need to iterate
until MDP5_INTF_NUM_MAX here.

Let's take the example of msm8x16:

 hw_cfg->intf.count = 1
 intfs[0] = INTF_Disabled
 intfs[1] = INTF_DSI

If we stop iterating once i reaches hw_cfg->intf.count (== 1),
we will miss the test for intfs[1].

Actually, this hw_cfg->intf.count entry is quite confusing and is not
(or *should not be*) used anywhere else; let's remove it.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>

This change adds the support in mdp5 kms driver for single
and dual DSI. Dual DSI case depends on the framework API
and sequence change to support dual data path.

v1: Initial change
v2: Address Rob Clark's comment
- Separate command mode encoder to a new file mdp5_cmd_encoder.c
- Rebase to not depend on msm_drm_sub_dev change
Signed-off-by: NHai Li <hali@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

This change adds the hw configuration for msm8x16 chipsets in
mdp5_cfg module.

Note that only one external display interface is present in this
configuration (DSI) but has not been enabled yet. It will be enabled
once drm/msm driver supports DSI connectors.

v2: add CTL flush register's hardware mask [pointed by Archit]
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

SMP blocks are configured for specific client IDs (ports).
These client IDs can be different from one chip to another for a
given pipe.

e.g.: DMA0 pipe fetch Y component is connected to:
 - port #10 for MDP5 v1.3
 - port #4 for MDP5 v1.6

In order to be compatible for upcoming versions of MDP5, the
client ID list is passed through the MDP5 config module rather
than using a list of hard-coded enum values.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

MDP block is actually contained inside the MDSS block. For some
chipsets, the base address of the MDP registers is different from the
current (assumed) 0x100 offset.

Like CTL and LM blocks, this changes introduce a dynamic offset
for the MDP instance, which can be found out at runtime, once the
MDSS HW version is read.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Pingpong register base addresses are different across platforms.
This change adds this information to config table and initialize
the values for 8x74 and 8084.
Signed-off-by: NHai Li <hali@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Up until now, we assume that eDP is tight to intf_0 and HDMI to
intf_3. This information shall actually come from the mdp5_cfg
module since it can change from one chip to another.

v2: rename macro to mdp5_cfg_intf_is_virtual() [pointed by Archit]
v3: add sanity check before writing in INTF_TIMING_ENGINE_EN registers
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Some interfaces (WB, DSI Command Mode) need to be kicked off
through a START Signal. This signal needs to be sent at the right
time and requests in some cases to keep track of the pipeline
status (eg: whether pipeline registers are flushed AND output WB
buffers are ready, in case of WB interface).
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

For example, use 'struct mdp5_smp *' everywhere instead of 'void *', but
only declare it as 'struct mdp5_smp;' in common headers, so the struct
body is still private.  The accomplishes the desired modularity while
still letting the compiler provide some type checking for us.
Signed-off-by: NRob Clark <robdclark@gmail.com>

The hardware configuration modification from a version to another
is quite consequent. Introducing a configuration module
(mdp5_cfg) may make things more clear and easier to access when a
new hardware version comes up.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>