This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
helpers.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

This patch adds the register ranges required for HDCP to the sc7180
device tree. These registers will be used to inject HDCP key as well as
toggle HDCP on and off.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

This patch adds the bindings for the MSM DisplayPort HDCP registers
which are required to write the HDCP key into the display controller as
well as the registers to enable HDCP authentication/key
exchange/encryption.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

Audio is initialized last, it should be de-initialized first to match
the order in dp_init_sub_modules().

Signed-off-by: Sean Paul <seanpaul@chromium.org>

encoder->commit() was being misused because there were some global
resources which needed to be tweaked in encoder->enable() which were not
accessible in dpu_encoder.c. That is no longer true and the redirect
serves no purpose any longer. So remove the indirection.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

A couple more useless checks to remove in dpu_encoder.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

Make includes alphabetical in dpu_kms.c

Signed-off-by: Sean Paul <seanpaul@chromium.org>

Now that all of the HDCP 1.x logic has been migrated to the central HDCP
helpers, use it in the i915 driver.

The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
however there are a few helper hooks which are connector-specific and
need to be partially or fully implemented in the intel_dp_hdcp.c or
intel_hdmi.c.

We'll leave most of the HDCP 2.x code alone since we don't have another
implementation of HDCP 2.x to use as reference for what should and
should not live in the drm helpers. The helper will call the overly
general enable/disable/is_capable HDCP 2.x callbacks and leave the
interesting stuff for the driver. Once we have another HDCP 2.x
implementation, we should do a similar migration.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

This patch expands upon the HDCP helper library to manage HDCP
enable, disable, and check.

Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once a new platform supported HDCP we could make good decisions
about what should be centralized. With the addition of HDCP support
for Qualcomm, it's time to migrate the protocol-specific bits of HDCP
authentication, key exchange, and link checks to the HDCP helper.

In terms of functionality, this migration is 1:1 with the Intel driver,
however things are laid out a bit differently than with intel_hdcp.c,
which is why this is a separate patch from the i915 transition to the
helper. On i915, the "shim" vtable is used to account for HDMI vs. DP
vs. DP-MST differences whereas the helper library uses a LUT to
account for the register offsets and a remote read function to route
the messages. On i915, storing the sink information in the source is
done inline whereas now we use the new drm_hdcp_helper_funcs vtable
to store and fetch information to/from source hw. Finally, instead of
calling enable/disable directly from the driver, we'll leave that
decision to the helper and by calling drm_hdcp_helper_atomic_commit()
from the driver. All told, this will centralize the protocol and state
handling in the helper, ensuring we collect all of our bugs^Wlogic
in one place.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

This patch updates the connector's property value in 2 cases which were
previously missed:

1- Content type changes. The value should revert back to DESIRED from
   ENABLED in case the driver must re-authenticate the link due to the
   new content type.

2- Userspace sets value to DESIRED while ENABLED. In this case, the
   value should be reset immediately to ENABLED since the link is
   actively being encrypted.

To accommodate these changes, I've split up the conditionals to make
things a bit more clear (as much as one can with this mess of state).

Signed-off-by: Sean Paul <seanpaul@chromium.org>

Instead of forcing a modeset in the hdcp atomic check, simply return
true if the content protection value is changing and let the driver
decide whether a modeset is required or not.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

This patch moves the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

# Conflicts:
#	arch/x86/events/rapl.c
#	mm/slub.c

# Conflicts:
#	drivers/gpu/drm/i915/i915_module.c
#	drivers/gpu/drm/ttm/ttm_bo_util.c

# Conflicts:
#	Documentation/gpu/drm-mm.rst
#	drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
#	drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
#	drivers/gpu/drm/i915/gem/i915_gem_ttm.c

# Conflicts:
#	drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
#	drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
#	drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
#	drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c
#	drivers/gpu/drm/i915/display/intel_display.c
#	drivers/gpu/drm/i915/i915_globals.c
#	drivers/gpu/drm/i915/i915_pci.c
#	drivers/gpu/drm/i915/intel_device_info.c
#	drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
#	drivers/gpu/drm/msm/dp/dp_display.c
#	drivers/gpu/drm/vmwgfx/vmwgfx_drv.h

…urcexxx()

Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately

Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately

Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210831135644.4576-1-caihuoqing@baidu.com

Valve's Steam Deck has a 800x1280 LCD screen.

Signed-off-by: Simon Ser <contact@emersion.fr>
Cc: Jared Baldridge <jrb@expunge.us>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Hans de Goede <hdegoede@redhat.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210911102430.253986-1-contact@emersion.fr

The Chuwi HiBook uses a panel which has been mounted
90 degrees rotated. Add a quirk for this.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210905130501.32980-1-hdegoede@redhat.com

Seeing these errors when GT is likely in suspend state-
"RPM wakelock ref not held during HW access"

Ensure GT is awake before trying to access HW registers. Avoid
reading the register if that is not the case.

Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Fixes: 41e5c17 ("drm/i915/guc/slpc: Sysfs hooks for SLPC")
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210907232704.12982-1-vinay.belgaumkar@intel.com

Usage of Transparent Hugepages was disabled in 9987da4
("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
appears majority of performance regressions reported with an enabled IOMMU
can be almost eliminated by turning them on, lets just do that.

To err on the side of safety we keep the current default in cases where
IOMMU is not active, and only when it is default to the "huge=within_size"
mode. Although there probably would be wins to enable them throughout,
more extensive testing across benchmarks and platforms would need to be
done.

With the patch and IOMMU enabled my local testing on a small Skylake part
shows OglVSTangent regression being reduced from ~14% (IOMMU on versus
IOMMU off) to ~2% (same comparison but with THP on).

More detailed testing done in the below referenced Gitlab issue by Eero:

Skylake GT4e:

Performance drops from enabling IOMMU:

    30-35% SynMark CSDof
    20-25% Unigine Heaven, MemBW GPU write, SynMark VSTangent
    ~20% GLB Egypt  (1/2 screen window)
    10-15% GLB T-Rex (1/2 screen window)
    8-10% GfxBench T-Rex, MemBW GPU blit
    7-8% SynMark DeferredAA + TerrainFly* + ZBuffer
    6-7% GfxBench Manhattan 3.0 + 3.1, SynMark TexMem128 & CSCloth
    5-6% GfxBench CarChase, Unigine Valley
    3-5% GfxBench Vulkan & GL AztecRuins + ALU2, MemBW GPU texture,
         SynMark Fill*, Deferred, TerrainPan*
    1-2% Most of the other tests

With the patch drops become:

    20-25% SynMark TexMem*
    15-20% GLB Egypt (1/2 screen window)
    10-15% GLB T-Rex (1/2 screen window)
    4-7% GfxBench T-Rex, GpuTest Triangle
    1-8% GfxBench ALU2 (offscreen 1%, onscreen 8%)
    3% GfxBench Manhattan 3.0, SynMark CSDof
    2-3% Unigine Heaven + Valley, MemBW GPU texture
    1-3 GfxBench Manhattan 3.1 + CarChase + Vulkan & GL AztecRuins

Broxton:

Performance drops from IOMMU, without patch:

    30% MemBW GPU write
    25% SynMark ZBuffer + Fill*
    20% MemBW GPU blit
    15% MemBW GPU blend, GpuTest Triangle
    10-15% MemBW GPU texture
    10% GLB Egypt, Unigine Heaven (had hangs), SynMark TerrainFly*
    7-9% GLB T-Rex, GfxBench Manhattan 3.0 + T-Rex,
         SynMark Deferred* + TexMem*
    6-8% GfxBench CarChase, Unigine Valley,
         SynMark CSCloth + ShMapVsm + TerrainPan*
    5-6% GfxBench Manhattan 3.1 + GL AztecRuins,
         SynMark CSDof + TexFilterTri
    2-4% GfxBench ALU2, SynMark DrvRes + GSCloth + ShMapPcf + Batch[0-5] +
         TexFilterAniso, GpuTest GiMark + 32-bit Julia

And with patch:

    15-20% MemBW GPU texture
    10% SynMark TexMem*
    8-9% GLB Egypt (1/2 screen window)
    4-5% GLB T-Rex (1/2 screen window)
    3-6% GfxBench Manhattan 3.0, GpuTest FurMark,
         SynMark Deferred + TexFilterTri
    3-4% GfxBench Manhattan 3.1 + T-Rex, SynMark VSInstancing
    2-4% GpuTest Triangle, SynMark DeferredAA
    2-3% Unigine Heaven + Valley
    1-3% SynMark Terrain*
    1-2% GfxBench CarChase, SynMark TexFilterAniso + ZBuffer

Tigerlake-H:

    20-25% MemBW GPU texture
    15-20% GpuTest Triangle
    13-15% SynMark TerrainFly* + DeferredAA + HdrBloom
    8-10% GfxBench Manhattan 3.1, SynMark TerrainPan* + DrvRes
    6-7% GfxBench Manhattan 3.0, SynMark TexMem*
    4-8% GLB onscreen Fill + T-Rex + Egypt (more in onscreen than
         offscreen versions of T-Rex/Egypt)
    4-6% GfxBench CarChase + GLES AztecRuins + ALU2, GpuTest 32-bit Julia,
         SynMark CSDof + DrvState
    3-5% GfxBench T-Rex + Egypt, Unigine Heaven + Valley, GpuTest Plot3D
    1-7% Media tests
    2-3% MemBW GPU blit
    1-3% Most of the rest of 3D tests

With the patch:

    6-8% MemBW GPU blend => the only regression in these tests (compared
         to IOMMU without THP)
    4-6% SynMark DrvState (not impacted) + HdrBloom (improved)
    3-4% GLB T-Rex
    ~3% GLB Egypt, SynMark DrvRes
    1-3% GfxBench T-Rex + Egypt, SynMark TexFilterTri
    1-2% GfxBench CarChase + GLES AztecRuins, Unigine Valley,
        GpuTest Triangle
    ~1% GfxBench Manhattan 3.0/3.1, Unigine Heaven

Perf of several tests actually improved with IOMMU + THP, compared to no
IOMMU / no THP:

    10-15% SynMark Batch[0-3]
    5-10% MemBW GPU texture, SynMark ShMapVsm
    3-4% SynMark Fill* + Geom*
    2-3% SynMark TexMem512 + CSCloth
    1-2% SynMark TexMem128 + DeferredAA

As a summary across all platforms, these are the benchmarks where enabling
THP on top of IOMMU enabled brings regressions:

 * Skylake GT4e:
   20-25% SynMark TexMem*
   (whereas all MemBW GPU tests either improve or are not affected)

 * Broxton J4205:
   7% MemBW GPU texture
   2-3% SynMark TexMem*

 * Tigerlake-H:
   7% MemBW GPU blend

Other benchmarks show either lowering of regressions or improvements.

v2:
 * Add Kconfig dependency to transparent hugepages and some help text.
 * Move to helper for easier handling of kernel build options.

v3:
 * Drop Kconfig. (Daniel)

v4:
 * Add some benchmark results to commit message.

v5:
 * Add explicit regression summary to commit message. (Eero)

References: b901bb8 ("drm/i915/gemfs: enable THP")
References: 9987da4 ("drm/i915: Disable THP until we have a GPU read BW W/A")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/430
Co-developed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210909114448.508493-1-tvrtko.ursulin@linux.intel.com

validate_lease expects one CRTC, one connector and one plane.

Signed-off-by: Simon Ser <contact@emersion.fr>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210903130000.1590-1-contact@emersion.fr

The ret value might be -EBUSY, caller will think lru lock is still
locked but actually NOT. So return -ENOSPC instead. Otherwise we hit
list corruption.

ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0,
caller(ttm_tt_populate -> ttm_global_swapout ->ttm_device_swapout) will
be stuck as we actually did not free any BO memory. This usually happens
when the fence is not signaled for a long time.

Signed-off-by: xinhui pan <xinhui.pan@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Fixes: ebd5985 ("drm/ttm: move swapout logic around v3")
Link: https://patchwork.freedesktop.org/patch/msgid/20210907040832.1107747-1-xinhui.pan@amd.com
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

…op.org/drm/drm-misc into drm-next

drm-misc-next-fixes for v5.15:
- Make some dma-buf config options depend on DMA_SHARED_BUFFER.
- Handle multiplication overflow of fbdev xres/yres in the core.

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

From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/37c5fe2e-5be8-45c3-286b-d8d536a5cef2@linux.intel.com

The "logicpd_type_28" panel data was splitting up the
mitsubishi_aa070mc01 panel data. Reorganize it so that the panel descs
and modes are kept together.

This is a no-op code-cleanup change, found by code inspection.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210901131531.v3.4.Ib2bdeceb8ce45d36c09f5d1ae62a2263276a0605@changeid

Android Hardware Composer supports alpha values applied to layers.
Enabling non-opaque layers for the STM CRTC could help offload GPU
resources for screen composition.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Reviewed-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210907151534.6013-1-raphael.gallais-pou@foss.st.com

Defines plane ordering by hard-coding an immutable Z position from the
first plane, used as primary layer, to the next ones as overlay in order
of instantiation.

This zpos is only an information as it is not possible to modify it,
blending operations are still applied from the top to the bottom layer.

This patch helps to remove a warning message from the Android
Hardware Composer.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Reviewed-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210907151323.5850-1-raphael.gallais-pou@foss.st.com

Fix the remaining warnings and finally enable this.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210908132933.3269-9-christian.koenig@amd.com

Fix the remaining warnings and finally enable this.

v2: add caching enum link

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210908132933.3269-8-christian.koenig@amd.com

Fix the last remaining warning and finally enable this.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210908132933.3269-7-christian.koenig@amd.com