Removes the traces of the non-atomic helper calls in
msm_pm_suspend/resume since we just deleted those functions (see patch
1). Also removes the drm_kms_helper_poll_disable/enable calls, since
the DRM_CONNECTOR_POLL_CONNECT flag is never set so periodic polling
doesn't happen anyways.
v2: reorganized patch order
v3: made error checks less severe
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Bruce Wang <bzwang@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
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>
Used by the dpu driver for custom suspend/resume.
Changes in v3:
- None
Signed-off-by: Jeykumar Sankaran <jsanka@codeaurora.org>
[seanpaul split this out of the megapatch]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Called right before wait_for_commit_done() to perform kickoff for
active crtcs.
Changes in v3:
- None
Signed-off-by: Jeykumar Sankaran <jsanka@codeaurora.org>
[seanpaul split this out of the megapatch]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
SoCs having mdp5 or dpu have identical tree like
device hierarchy where MDSS top level wrapper manages
common power resources for all child devices.
Subclass msm_mdss so that msm_mdss includes common defines
and mdp5/dpu mdss derivations to include any extensions.
Add mdss helper interface (msm_mdss_funcs) to msm_mdss
base for mdp5/dpu mdss specific implementation calls.
This change subclasses msm_mdss for mdp5, dpu specific
changes will be done separately.
Changes in v3:
- Added Archit's R-b
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rajesh Yadav <ryadav@codeaurora.org>
[seanpaul rebased on msm-next and resolved conflicts]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
With the addition of "private_objs" in drm_atomic_state, we no longer
need to subclass drm_atomic_state to store state of share resources
that don't perfectly fit within planes/crtc/connector state information.
We can now save this state within drm_atomic_state itself using
the private objects.
Remove the infrastructure that allowed subclassing of drm_atomic_state
in the driver.
Changes in v3:
- Added to the msm atomic helper patch set
Changes in v4:
- None
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
This change plumbs the new fb modifier through the various mdp/disp
get_format hooks.
Signed-off-by: Jeykumar Sankaran <jsanka@codeaurora.org>
[seanpaul pimped out commit message a bit]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
other sub-blocks. W.r.t device heirarchy, it's the parent of all these
devices. The power domain of this device is actually tied to the GDSC
hw. When any sub-device enables its PD, MDSS's PD is also enabled.
The suspend/resume ops enable the top level clocks that end at the MDSS
boundary. For now, we're letting them all be optional, since the child
devices anyway hold a ref to these clocks.
Until now, we'd called a runtime_get() during probe, which ensured that
the GDSC was always on. Now that we've set up runtime PM for the children
devices, we can get rid of this hack.
Note: that the MDSS device is the platform_device in msm_drv.c. The
msm_runtime_suspend/resume ops call the funcs that enable/disable
the top level MDSS clocks. This is different from MDP4, where the
platform device created in msm_drv.c represents MDP4 itself. It would
have been nicer to hide these differences by adding new kms funcs, but
runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
is called).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Now that the msm_gem supports an arbitrary number of vma's, we no longer
need to assign an id (index) to each address space. So rip out the
associated code.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Before we can shift to passing the address-space object to _get_iova(),
we need to fix a few places (dsi+fbdev) that were hard-coding the adress
space id. That gets somewhat easier if we just move these to the kms
base class.
Prep work for next patch.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Move the contents of msm_debugfs_cleanup() to msm_drm_uninit() to free
up the drm_driver->debugfs_cleanup callback. Also remove the
mdp_kms_funcs->debugfs_cleanup callback which has no users.
Cc: robdclark@gmail.com
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170307204924.1002-2-noralf@tronnes.org
The mdp5 kms driver currently sets up multiple encoders per interface
(INTF), one for each kind of mode of operation it supports.
We create 2 drm_encoders for DSI, one for Video Mode and the other
for Command Mode operation. The reason behind this approach could have
been that we aren't aware of the DSI device's mode of operation when
we create the encoders.
This makes things a bit complicated, since these encoders have to
be further attached to the same DSI bridge. The easier way out is
to create a single encoder, and make the DSI driver set its mode
of operation when we know what the DSI device's mode flags are.
Start with providing a way to set the mdp5_intf_mode using a kms
func that sets the encoder's mode of operation. When constructing
a DSI encoder, we set the mode of operation to Video Mode as
default. When the DSI device is attached to the host, we probe the
DSI mode flags and set the corresponding mode of operation.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
With the new kms_init/destroy funcs in place for MDP5, we can get rid of
the old kms funcs. Some members of the mdp5_kms struct also become
redundant, so we remove those too.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
With MDP5 as a new device, we need to do less for MDP when initializing
modeset after all the components are bound.
Create mdp5_kms_init2/destroy2 funcs that inits modeset. These will
eventually replace the older kms_init/destroy funcs.
In the new kms_init2, the platform_device used is the one corresponding
to the new MDP5 platform_device. The new change here is that the irq is
now retrieved using irq_of_parse_and_map(), since MDP5 is a child interrupt
of the MDSS interrupt controller.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
SoCs that contain MDP5 have a top level wrapper called MDSS that manages
clocks, power and irq for the sub-blocks within it.
Currently, the MDSS portions are stuffed into the MDP5 driver. This makes
it hard to represent the DT bindings in the correct way. We create a top
level MDSS helper that handles these parts. This is essentially moving out
some of the mdp5_kms irq code and MDSS register space and keeping it as a
separate entity. We haven't given any clocks to the top level MDSS yet,
but a AHB clock would be added in the future to access registers.
One thing to note is that the resources allocated by this helper are
tied to the top level platform_device (the one that allocates the
drm_device struct too). This device would be the parent to MDSS
sub-blocks like MDP5, DSI, eDP etc.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The driver gets the irq number using platform_get_irq on the main kms
platform device. This works fine since both MDP4 and MDP5 currently
have a flat device hierarchy. The platform device tied with the
drm_device points to the MDP DT node in both cases.
This won't work when MDP5 supports a tree-like hierarchy. In this
case, the platform device tied to the top level drm_device is the
MDSS DT node, and the irq we need for KMS is the one generated by
MDP5, not MDSS.
Get the irq number from the MDP4/5 kms driver itself. Each driver
can later provide the irq number based on what device hierarchy it
uses.
While we're at it, call drm_irq_install only when we have a valid KMS
driver.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
These aren't used. Probably left overs when driver was refactored to
support both MDP4 and MDP5.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 53190c7194
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
AuthorDate: Mon Jan 25 22:16:49 2016 +0100
Commit: Daniel Vetter <daniel.vetter@ffwll.ch>
CommitDate: Mon Feb 8 09:55:50 2016 +0100
drm/msm: Nuke preclose hooks
Left around the unused (and null) preclose fxn ptr, and things
predictibly explode when you try to call that.
Signed-off-by: Rob Clark <robdclark@gmail.com>
MDP FLUSH registers could indicate if the previous flush updates
has taken effect at vsync boundary. Making use of this H/W feature
can catch the vsync that happened between CRTC atomic_flush and
*_wait_for_vblanks, to avoid unnecessary wait.
This change allows kms CRTCs to use their own *_wait_for_commit_done
functions to wait for FLUSH register cleared at vsync, before commit
completion.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This change is to add an interface to MDP for connector devices
setting split display information.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Both MDP4 and MDP5 share some code as far as YUV support is
concerned. This change adds this information and will be followed
by the actual MDP4 and MDP5 YUV support patches.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
As a result of atomic DPMS support, the various prepare/commit hooks get
called in a way that msm dislikes. We were expecting prepare/commit to
bracket a modeset, which is no longer the case. This was needed to hold
various extra clk's (such as interface clks) on while we are touching
registers, and in the case of mdp4 holding vblank enabled.
The most straightforward way to deal with this, since we already have
our own atomic_commit(), is to just handle prepare/commit internally to
the driver (with some additional vfuncs for mdp4 vs mdp5), and switch
everything over to instead use the new enable/disable hooks. It doesn't
really change too much, despite the code motion. What used to be in the
encoder/crtc dpms() fxns is split out into enable/disable.
We should be able to drop our own enable-state tracking, as the atomic
helpers should do this for us. But keeping that for the short term for
extra debugging as atomic stablizes.
Signed-off-by: Rob Clark <robdclark@gmail.com>
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>
