Currently the DRM fbcon helper for console blank,
drm_fb_helper_blank(), simply calls drm_fb_helper_dpms() and always
returns zero, supposing the driver dealing with DPMS or atomic
crtc->active flip to handle blanking the screen.  It works on most of
devices, but broken on most of KVM/QEMU graphics: bochs, qxl and
cirrus drivers just ignore crtc->active state change as blanking (or
cirrus ignoring DPMS).  In practice, when you run like
  % setterm --blank force
on a VT console, the screen freezes without actually blanking.

A simple fix for this problem would be not to rely on DPMS but let
fbcon performs the generic blank code.  This can be achieved just by
returning an error from drm_fb_helper_blank().

In this patch, we add a flag, no_dpms_blank, to drm_fb_helper for
indicating that the driver doesn't handle blank via DPMS or
crtc->active flip.  When this flag is set, drm_fb_helper_blank()
simply returns an error, so that fbcon falls back to its generic blank
handler.  The flag is set to both bochs and qxl drivers in this patch,
while cirrus is left untouched as it's declared as to-be-deprecated.

Link: https://lore.kernel.org/dri-devel/20170726205636.19144-1-tiwai@suse.de/
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1095700
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Fix redundant condition, caught in cppcheck by kernel test robot.

Reported-by: kernel test robot <lkp@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Fixes: b64d6c5 ("drm/i915/display: Support PSR Multiple Instances")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Harish Chegondi <harish.chegondi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210409231738.238682-1-jose.souza@intel.com

The address-of op in front of an array is just an alias to using the
array on its own, so drop the op.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210412232413.2755054-2-imre.deak@intel.com

In case AUX failures happen unexpectedly during a modeset, the driver
should still complete the modeset. In particular the driver should
perform the link training sequence steps even in case of an AUX failure,
as this sequence also includes port initialization steps. Not doing that
can leave the port/pipe in a broken state and lead for instance to a
flip done timeout.

Fix this by continuing with link training (in a no-LTTPR mode) if the
DPRX DPCD readout failed for some reason at the beginning of link
training. After a successful connector detection we already have the
DPCD read out and cached, so the failed repeated read for it should not
cause a problem. Note that a partial AUX read could in theory partly
overwrite the cached DPCD (and return error) but this overwrite should
not happen if the returned values are corrupted (due to a timeout or
some other IO error).

Kudos to Ville to root cause the problem.

Fixes: 264613b ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3308
Cc: stable@vger.kernel.org # 5.11
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210412232413.2755054-1-imre.deak@intel.com

…ations"

This reverts commit 71c1a49.

The proper fix is Wa_14013723622, so now we can revert this WA and
get back some power savings.

Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408204917.254272-2-jose.souza@intel.com

This WA fix some display glitches when the system is under high
memory pressure.

BSpec: 52890
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408204917.254272-1-jose.souza@intel.com

Instead of sleeping panel_pwr_cycle_delay ms when turning the panel off,
record the time it is turned off and if necessary wait any (remaining)
time when the panel is turned on again.

Also sleep the remaining time on shutdown, because on reboot the
GOP will immediately turn on the panel again.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325114823.44922-2-hdegoede@redhat.com

…bling the panel

After the recently added commit fe0f1e3 ("drm/i915: Shut down
displays gracefully on reboot"), the DSI panel on a Cherry Trail based
Predia Basic tablet would no longer properly light up after reboot.

I've managed to reproduce this without rebooting by doing:
chvt 3; echo 1 > /sys/class/graphics/fb0/blank;\
echo 0 > /sys/class/graphics/fb0/blank

Which rapidly turns the panel off and back on again.

The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various delays
used for panel on/off, since starting with MIPI-sequences version >= 3 the
delays are already included inside the MIPI-sequences.

The problems exposed by the "Shut down displays gracefully on reboot"
change, show that using this helper for the panel_pwr_cycle_delay is
not the right thing to do. This has not been noticed until now because
normally the panel never is cycled off and directly on again in quick
succession.

Change the msleep for the panel_pwr_cycle_delay to a normal msleep()
call to avoid the panel staying black after a quick off + on cycle.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: fe0f1e3 ("drm/i915: Shut down displays gracefully on reboot")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325114823.44922-1-hdegoede@redhat.com

PSR2 is defeatured for RKL and ADL-S, no important power impact as
those are desktop CPUs and PSR2 was not even enabled by default yet
in platforms without PSR2 HW tracking.

HSDES: 14011750631
HSDES: 14011741325
BSpec: 53273
Cc: Caz Yokoyama <Caz.Yokoyama@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408214205.327704-1-jose.souza@intel.com

Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.

Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.

We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.

Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-3-jose.souza@intel.com

Power wells are only part of display block and not necessary when
running a headless driver.

Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-2-jose.souza@intel.com

Return ealier in the functions doing interruption setup for GEN8+ also
adding a warning in gen8_de_irq_handler() to let us know that
something else is still missing.

Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-1-jose.souza@intel.com

Fix static analysis tool uninitialized symbol error.

v2:
- use ktime_set(0, 0) instead to initialize to zero. [Ankit]

Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408082642.27066-1-anshuman.gupta@intel.com

Don't zero out the watermarks for the Y plane since we've already
computed them when computing the UV plane's watermarks (since the
UV plane always appears before ethe Y plane when iterating through
the planes).

This leads to allocating no DDB for the Y plane since .min_ddb_alloc
also gets zeroed. And that of course leads to underruns when scanning
out planar formats.

Cc: stable@vger.kernel.org
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: dbf7138 ("drm/i915: Nuke intel_atomic_crtc_state_for_each_plane_state() from skl+ wm code")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210327005945.4929-1-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Looks like that there actually are another subset of laptops on the market
that don't support the Intel HDR backlight interface, but do advertise
support for the VESA DPCD backlight interface despite the fact it doesn't
seem to work.

Note though I'm not entirely clear on this - on one of the machines where
this issue was observed, I also noticed that we appeared to be rejecting
the VBT defined backlight frequency in
intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:

/* Use highest possible value of Pn for more granularity of brightness
 * adjustment while satifying the conditions below.
 * ...
 * - FxP is within 25% of desired value.
 *   Note: 25% is arbitrary value and may need some tweak.
 */

So it's possible that this value might just need to be tweaked, but for now
let's just disable the VESA backlight interface unless it's specified in
the VBT just to be safe. We might be able to try enabling this again by
default in the future.

Fixes: 2227816 ("drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight")
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210318170204.513000-1-lyude@redhat.com

Sync up with topic/i915-gem-next and drm-intel-gt-next.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

…g/drm/drm-intel into drm-next

Features:
- Add support for FBs requiring a power-of-two stride padding (Imre)

Refactoring:
- Disassociate display version from gen (Matt)
- Refactor legacy DP and HDMI code to separate files (Ville)
- Refactor FB plane code to a separate file (Imre)
- Refactor VBT child device info parsing and usage (Jani)
- Refactor KBL/TGL/ADL-S display and gt stepping schemes (Jani)

Fixes:
- DP Link-Training Tunable PHY Repeaters (LTTPR) fixes (Imre)
- HDCP fixes (Anshuman)
- DP 2.0 HDMI 2.1 PCON Fixed Rate Link (FRL) fixes (Ankit)
- Set HDA link parameters in driver (Kai)
- Fix enabled_planes bitmask (Ville)
- Fix transposed arguments to skl_plane_wm_level() (Ville)
- Stop adding planes to the commit needlessly (Ville)

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

From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/87v996ml17.fsf@intel.com

….org/drm/drm-intel into drm-next

Driver Changes:

- Prepare for local/device memory support on DG1 by starting
  to use it for kernel internal allocations: context, ring
  and engine scratch (Matt A, CQ, Abdiel, Imre)
- Sandybridge fix to avoid hard hang on ring resume (Chris)
- Limit imported dma-buf size to int32 (Matt A)
- Double check heartbeat timeout before resetting (Chris)

- Use new tasklet API for execution list (Emil)
- Fix SPDX checkpats warnings (Chris)
- Fixes for various checkpatch warnings (Chris)
- Selftest improvements (Chris)
- Move the defer_request waiter active assertion to correct spot (Chris)
- Make local-memory probing a GT operation (Matt, Tvrtko)
- Protect against request freeing during cancellation on wedging (Chris)
- Retire unexpected starting state error dumping (Chris)
- Distinction of memory regions in debugging (Zbigniew)
- Always flush the submission queue on checking for idle (Chris)

- Consolidate 2big error check to helper (Matt)
- Decrease number of subplatform bits (Tvrtko)
- Remove unused internal request priority levels (Chris)
- Document the unused internal header bits in buddy allocator (Matt)
- Cleanup the region class/instance encoding (Matt)

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

From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YGxksaZGXHnFxlwg@jlahtine-mobl.ger.corp.intel.com

…linux/kernel/git/chunkuang.hu/linux into drm-next

Mediatek DRM Next for Linux 5.13

1. Fine tune the line time for EOTp.
2. Add support mt8192 dpi.
3. Make crtc config-updating atomic.
4. Don't support hdmi connector creation.

From: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210405082248.3578-1-chunkuang.hu@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the
display code, we should also kill off our use of the IS_GEN9_* macros
too.  We'll do the conversion manually this time instead of using
Coccinelle since the most logical substitution can depend heavily on the
code context, and sometimes we can keep the code simpler if we make
additional adjustments such as swapping the order of if/else arms.

v2:
 - Restore a lost negation in intel_pll_is_valid().

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com

intel_dsm_platform_mux_info() tries to parse the ACPI package data
from _DSM for the debug information, but it assumes the fixed format
without checking what values are stored in the elements actually.
When an unexpected value is returned from BIOS, it may lead to GPF or
NULL dereference, as reported recently.

Add the checks of the contents in the returned values and skip the
values for invalid cases.

v1->v2: Check the info contents before dereferencing, too

BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210402082317.871-1-tiwai@suse.de

…/drm/drm-misc into drm-next

drm-misc-next for 5.13:

UAPI Changes:

Cross-subsystem Changes:

Core Changes:
  - mst: Improve topology logging
  - edid: Rework and improvements for displayid

Driver Changes:
  - anx7625: Regulators support
  - bridge: Support for the Chipone ICN6211, Lontium LT8912B
  - lt9611: Fix 4k panels handling

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

From: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210401110552.2b3yetlgsjtlotcn@gilmour

Fix the following coccicheck warning:
drivers/gpu/drm/i915//i915_sysfs.c:266:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:285:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:276:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:335:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:390:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:465:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:107:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:75:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:83:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:91:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:99:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:326:8-16:
WARNING: use scnprintf or sprintf

Signed-off-by: Xuezhi Zhang <zhangxuezhi1@yulong.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210404084103.528211-1-llyz108@163.com

Due to the changed sequence of activating/deactivating DC3CO, disable
DC3CO until the changed dc3co activating/deactivating sequence is applied.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/3134
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210401170237.40472-1-gwan-gyeong.mun@intel.com

We need to wait for the DMC FW loader work to complete during shutdown,
even if it's unlikely to be still pending by that time, fix this.

This also fixes the wakeref tracking WARN during shutdown about the
leaked reference we hold due to a missing DMC firmware.

While at it add a TODO comment about unifying the shutdown and PM
power-off sequences and later these sequences with the driver remove and
system/runtime suspend sequences.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://lore.kernel.org/lkml/20210303055517.GB2708@xsang-OptiPlex-9020
Reported-and-tested-by: kernel test robot <oliver.sang@intel.com>
Reported-and-tested-by: Edward Baker <edward.baker@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210311144529.3059024-1-imre.deak@intel.com

According to bspec icl+ no longer need any extra cdclk guardband
for 64bpp formats. Make it so.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210330162416.18616-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Split the glk+ stuff into it's own version of the .min_cdclk()
vfunc.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210330162416.18616-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

commit f011951 ("drm/mediatek: mtk_dpi: Create connector for bridges")
broke the display support for elm device since mtk_dpi calls
drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
while mtk_hdmi does not yet support this flag.

Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in bridge attachment.
Implement the drm_bridge_funcs .detect() and .get_edid() operations, and
call drm_bridge_hpd_notify() to report HPD. This provides the
necessary API to support disabling connector creation.

In addition, the field 'conn' is removed from the mtk_hdmi struct since
mtk_hdmi don't create a connector. It is replaced with a pointer
'curr_conn' that points to the current connector which can be access
through the global state.

This patch is inspired by a similar patch for bridge/synopsys/dw-hdmi.c:
commit ec971aa
("drm: bridge: dw-hdmi: Make connector creation optional")
But with the difference that in mtk-hdmi only the option of not creating
a connector is supported.

Fixes: f011951 ("drm/mediatek: mtk_dpi: Create connector for bridges")
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>

The bridge operation '.enable' and the audio cb '.get_eld'
access hdmi->conn. In the future we will want to support
the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will
not have direct access to the connector.
The atomic version '.atomic_enable' allows accessing the
current connector from the state.
This patch switches the bridge to the atomic version to
prepare access to the connector in later patches.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>

When suspending the driver, anx7625_power_standby() will be called to
turn off reset-gpios and enable-gpios. However, power supplies are not
disabled. To save power, the driver can get the power supply regulators
and turn off them in anx7625_power_standby().

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Reviewed-by: Xin Ji <xji@analogixsemi.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210401053202.159302-2-hsinyi@chromium.org

anx7625 requires 3 power supply regulators.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210401053202.159302-1-hsinyi@chromium.org

…/linux/kernel/git/daeinki/drm-exynos into drm-next

One cleanup
- Based on the patch[1], clean up the use of request_irq function
  series.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/?id=cbe16f35bee6880becca6f20d2ebf6b457148552

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

From: Inki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1617092998-23645-1-git-send-email-inki.dae@samsung.com

…rg/git/drm/drm into drm-next

special i915-gem-next pull as requested

- Conversion to dma_resv_locking, obj->mm.lock is gone (Maarten, with
  help from Thomas Hellström)
- watchdog (Tvrtko, one patch to cancel individual request from Chris)
- legacy ioctl cleanup (Jason+Ashutosh)
- i915-gem TODO and RFC process doc (me)
- i915_ prefix for vma_lookup (Liam Howlett) just because I spotted it
  and put it in here too

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

From: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/YF24MHoOSjpKFEXA@phenom.ffwll.local

Fix the

Documentation/gpu/i915:22: /drivers/gpu/drm/i915/intel_runtime_pm.c:423: WARNING: Inline strong start-string without end-string.

warning from the htmldocs build.

Fixes: 9d58aa4 ("drm/i915: Fix the GT fence revocation runtime PM logic")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210330150118.1105079-1-imre.deak@intel.com

Avoid any confusion with High Dynamic Range. No functional changes.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ce083bd2789c7e22a91710726162287db88e3f6c.1617024940.git.jani.nikula@intel.com