Commit Graph

9 Commits

Author SHA1 Message Date
Linus Walleij
86fe3f546e drm/msm/dpu: Drop unused GPIO code
The DPU has some kind of idea that it wants to be able to
bring up power using GPIO lines. The struct dss_gpio is however
completely unused and should this be done, it should be done
using the GPIO descriptor framework rather than this API
which relies on the global GPIO numberspace. Delete this
code before anyone hurt themselves.

The inclusion of <linux/gpio.h> was abused to get some OF
and IRQ headers implicitly included into the DPU utilities,
make these includes explicit and push them down into the actual
implementation.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Sean Paul <sean@poorly.run>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-09-03 16:16:58 -07:00
Dave Airlie
53e155f2bb Merge tag 'drm-msm-next-2019-06-25' of https://gitlab.freedesktop.org/drm/msm into drm-next
+ usual progress on cleanups
+ dsi vs EPROBE_DEFER fixes
+ msm8998 (snapdragon 835 support)
  + a540 gpu support (mesa support already landed)
  + dsi, dsi-phy support
+ mdp5 and dpu interconnect (bus/memory scaling) support
+ initial prep work for per-context pagetables (at least the parts that
  don't have external dependencies like iommu/arm-smmu)

There is one more patch for fixing DSI cmd mode panels (part of a set of
patches to get things working on nexus5), but it would be conflicty with
1cff7440a8 in drm-next without rebasing or back-merge,
and since it doesn't conflict with anything in msm-next, I think it best
if Sean merges that through drm-mix-fixes instead.

(In other news, I've been making some progress w/ getting efifb working
properly on sdm850 laptop without horrible hacks, and drm/msm + clk stuff
not totally falling over when bootloader enables display and things are
already running when driver probes.. but not quite ready yet, hopefully
we can post some of that for 5.4.. should help for both the sdm835 and
sdm850 laptops.)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsj3N4XzDLSDoa+4RHZ9wXObYmhcep0M3LjnRg48BeLvg@mail.gmail.com
2019-06-28 10:16:40 +10:00
Jordan Crouse
36415615ad drm/msm/dpu: Fix error recovery after failing to enable clocks
If enabling clocks fails in msm_dss_enable_clk() the code to unwind the
settings starts at 'i' which is the clock that just failed. While this
isn't harmful it does result in a number of warnings from the clock
subsystem while trying to unpreare/disable the very clock that had
just failed to prepare/enable. Skip the current failed clock during
the unwind to to avoid the extra log spew.

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-06-18 13:52:10 -07:00
Thomas Gleixner
97fb5e8d9b treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 284
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 and
  only 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

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 294 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Alexios Zavras <alexios.zavras@intel.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190529141900.825281744@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05 17:36:37 +02:00
Mamta Shukla
6a41da17e8 drm: msm: Use DRM_DEV_* instead of dev_*
Use DRM_DEV_INFO/ERROR/WARN instead of dev_info/err/debug to generate
drm-formatted specific log messages so that it will be easy to
differentiate in case of multiple instances of driver.

Signed-off-by: Mamta Shukla <mamtashukla555@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-12-11 13:05:22 -05:00
Kees Cook
329e098939 treewide: Replace more open-coded allocation size multiplications
As done treewide earlier, this catches several more open-coded
allocation size calculations that were added to the kernel during the
merge window. This performs the following mechanical transformations
using Coccinelle:

	kvmalloc(a * b, ...) -> kvmalloc_array(a, b, ...)
	kvzalloc(a * b, ...) -> kvcalloc(a, b, ...)
	devm_kzalloc(..., a * b, ...) -> devm_kcalloc(..., a, b, ...)

Signed-off-by: Kees Cook <keescook@chromium.org>
2018-10-05 18:06:30 -07:00
Gustavo A. R. Silva
aff24cd1f5 drm/msm: Replace PTR_RET with PTR_ERR_OR_ZERO
PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-07-30 08:50:12 -04:00
Sean Paul
41a8e8865a drm/msm: dpu: Use clock-names instead of assigned-clock-names
In these cases, we want to enumerate _all_ clocks, not just the ones
that are assigned a rate.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-07-30 08:50:12 -04:00
Jeykumar Sankaran
25fdd5933e drm/msm: Add SDM845 DPU support
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>
2018-07-26 10:45:04 -04:00