Commit Graph

8 Commits

Author SHA1 Message Date
Dave Airlie 8c1a765bc6 drm-misc-next for 5.1:
UAPI Changes:
 
 Cross-subsystem Changes:
   - Turn dma-buf fence sequence numbers into 64 bit numbers
 
 Core Changes:
   - Move to a common helper for the DP MST hotplug for radeon, i915 and
     amdgpu
   - i2c improvements for drm_dp_mst
   - Removal of drm_syncobj_cb
   - Introduction of an helper to create and attach the TV margin properties
 
 Driver Changes:
   - Improve cache flushes for v3d
   - Reflection support for vc4
   - HDMI overscan support for vc4
   - Add implicit fencing support for rockchip and sun4i
   - Switch to generic fbdev emulation for virtio
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXDOTqAAKCRDj7w1vZxhR
 xZ8QAQD4j8m9Ea3bzY5Rr8BYUx1k+Cjj6Y6abZmot2rSvdyOHwD+JzJFIFAPZjdd
 uOKhLnDlubaaoa6OGPDQShjl9p3gyQE=
 =WQGO
 -----END PGP SIGNATURE-----

Merge tag 'drm-misc-next-2019-01-07-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

drm-misc-next for 5.1:

UAPI Changes:

Cross-subsystem Changes:
  - Turn dma-buf fence sequence numbers into 64 bit numbers

Core Changes:
  - Move to a common helper for the DP MST hotplug for radeon, i915 and
    amdgpu
  - i2c improvements for drm_dp_mst
  - Removal of drm_syncobj_cb
  - Introduction of an helper to create and attach the TV margin properties

Driver Changes:
  - Improve cache flushes for v3d
  - Reflection support for vc4
  - HDMI overscan support for vc4
  - Add implicit fencing support for rockchip and sun4i
  - Switch to generic fbdev emulation for virtio

Signed-off-by: Dave Airlie <airlied@redhat.com>

[airlied: applied amdgpu merge fixup]
From: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190107180333.amklwycudbsub3s5@flea
2019-01-10 05:58:52 +10: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
Rob Clark b962a12050 drm/atomic: integrate modeset lock with private objects
Follow the same pattern of locking as with other state objects. This
avoids boilerplate in the driver.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022123122.30468-1-boris.brezillon@bootlin.com
2018-12-11 15:24:30 +01:00
Sean Paul a5c6b59904 drm/msm: Move wait_for_vblanks into mdp complete_commit() hooks
DPU doesn't use this, so push it into the mdp drivers.

Changes in v3:
- None

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rajesh Yadav <ryadav@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-07-26 10:40:15 -04:00
Archit Taneja c21c731d93 drm/msm: Don't subclass drm_atomic_state anymore
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>
2018-06-03 16:49:00 -04:00
Archit Taneja 7907a0d77c drm/msm/mdp5: Use the new private_obj state
This replaces the usage of the subclassed atomic state (mdp5_state)
with a private_obj state embedded within drm_atomic_state. The latter
method is the preferred approach, since it's simpler to implement
and less prone to errors.

The new API replaces the older and equivalent mdp5_state usage in the
following pattern:
- References to "mdp5_kms->state" (i.e, the old/existing state) is
  replaced with mdp5_get_existing_global_state(). In the atomic_check
  path, this should be called with the glob_state_lock drm_modeset_lock
  alredy taken.
- References to "mdp5_get_state()" are replaced with
  mdp5_get_global_state(). This acquires glob_state_lock and uses
  drm_atomic_get_private_obj_state() to create a new duplicated state.

Changes in v3:
- Acquire glob_state_lock in mdp5_smp.c
- 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>
2018-06-03 16:49:00 -04:00
Archit Taneja 8d58ef346f drm/msm/mdp5: Add global state as a private atomic object
Global shared resources (hwpipes, hwmixers and SMP) for MDP5 are
implemented as a part of atomic state by subclassing drm_atomic_state.

The preferred approach is to use the drm_private_obj infrastructure
available in the atomic core.

mdp5_global_state is introduced as a drm atomic private object. The two
funcs mdp5_get_global_state() and mdp5_get_existing_global_state() are
the two variants that will be used to access mdp5_global_state.

This will replace the existing mdp5_state struct (which subclasses
drm_atomic_state) and the funcs around it. These will be removed later
once we mdp5_global_state is put to use everywhere.

Changes in v3:
- Added glob_state_lock instead of pushing it into the core
- 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>
2018-06-03 16:49:00 -04:00
Rob Clark 14be3200cd drm/msm: rename mdp->disp
Since new display controller is called "dpu" instead of "mdp".  Lets
make the name of the toplevel directory for the display controllers a
bit more generic.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
2018-03-19 06:33:35 -04:00