drm/i915: Add macros to get i915 device from i915_gem_object

We want to stop touching directly i915_gem_object struct members in
intel_frontbuffer code. As a part of this we add helper macro to get i915
device from i915_gem_object.

v2: operate on and return pointer in defined macros

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727064142.751976-2-jouni.hogander@intel.com

drm/i915/color: Downscale degamma lut values read from hardware

For MTL and beyond, convert back the 24 bit lut values
read from HW to 16 bit values to maintain parity with
userspace values. This way we avoid pipe config mismatch
for pre-csc lut values.

v2: Add helper function to downscale values (Jani)

Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230725083002.3779717-3-chaitanya.kumar.borah@intel.com

drm/i915/color: Upscale degamma values for MTL

MTL onwards Degamma LUT/PRE-CSC LUT precision has been increased from
16 bits to 24 bits. Currently, drm framework only supports LUTs up to 16
bit precision. Until a new uapi comes along to support higher bitdepth,
upscale the values sent from userland to 24 bit before writing into the
HW to continue supporting degamma on MTL.

Add helper function to upscale or downscale lut values. Parameters
'to' and 'from' needs to be less than 32. This should be sufficient
as currently there are no lut values exceeding 32 bit.

v2: (Jani)
    - Reuse glk_load_degamma_lut()
    - Create a helper function for upscaling values

v3: Fix multi line comment style (Uma)
v4: Remove extra line(Ankit)

Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727123342.4077017-1-chaitanya.kumar.borah@intel.com

drm/i915/hotplug: Reduce SHPD_FILTER to 250us

On TGP, the RTC (always running) was reduced from 3MHz to 32KHz.
As a result of this change, when HPD active going low pulse or HPD IRQ
is presented and the refclk (19.2MHz) is not toggling already toggling,
there is a 60 to 90us synchronization delay which effectively reduces
the duration of the IRQ pulse to less than the programmed 500us filter
value and the hot plug interrupt is NOT registered.
Solution was to Reduce SHPD_FILTER to 250us for ADL and above.
This solution was derived when the below patch was floated.
[1]https://patchwork.freedesktop.org/patch/532187
and after some internal discussion Ville's suggestion made sense.

Bspec: 68970

Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230720104624.3063544-1-suraj.kandpal@intel.com

drm/i915: Simplify expression &to_i915(dev)->drm

to_i915 is defined as

container_of(dev, struct drm_i915_private, drm);

So for a struct drm_device *dev, to_i915(dev)->drm is just dev. Simplify
accordingly.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230721212133.271118-1-u.kleine-koenig@pengutronix.de

drm/i915/dpt: Use shmem for dpt objects

Dpt objects that are created from internal get evicted when there is
memory pressure and do not get restored when pinned during scanout. The
pinned page table entries look corrupted and programming the display
engine with the incorrect pte's result in DE throwing pipe faults.

Create DPT objects from shmem and mark the object as dirty when pinning so
that the object is restored when shrinker evicts an unpinned buffer object.

v2: Unconditionally mark the dpt objects dirty during pinning(Chris).

Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt")
Cc: <stable@vger.kernel.org> # v6.0+
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
Signed-off-by: Fei Yang <fei.yang@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230718225118.2562132-1-radhakrishna.sripada@intel.com

drm/i915: Start using plane scale factor for relative data rate

BSpec clearly instructs us to use plane scale factor when calculating
relative data rate to be used when allocating DDB blocks for each plane.
For some reason we use scale factor for data_rate calculation, which is
used for BW calculations, however we are not using it for DDB calculations.
So lets fix it as described in BSpec 68907.

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Garg, Nemesa <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230719104833.25366-1-stanislav.lisovskiy@intel.com

drm/i915/display: Do not use stolen on MTL

Use smem on MTL due to a HW bug in MTL that prevents
reading from stolen memory using LMEM BAR.

v2 and v3: improve stolen skip detection(Andrzej)

Cc: Oak Zeng <oak.zeng@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Oak Zeng <oak.zeng@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230713150142.12700-2-nirmoy.das@intel.com

Revert "drm/i915: use localized __diag_ignore_all() instead of per file"

This reverts commit 88e9664434c994e97a9f6f8cdd1535495c660cea.

__diag_ignore_all() only works for GCC 8 or later.

-Woverride-init (from -Wextra, enabled in i915 Makefile) combined with
CONFIG_WERROR=y or W=e breaks the build for older GCC.

With i386_defconfig and x86_64_defconfig enabling CONFIG_WERROR=y by
default, we really need to roll back the change.

An alternative would be to disable -Woverride-init in the Makefile for
GCC <8, but the revert seems like the safest bet now.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8768
Reported-by: John Garry <john.g.garry@oracle.com>
References: https://lore.kernel.org/r/ad2601c0-84bb-c574-3702-a83ff8faf98c@oracle.com
References: https://lore.kernel.org/r/87wmzezns4.fsf@intel.com
Fixes: 88e9664434c9 ("drm/i915: use localized __diag_ignore_all() instead of per file")
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Tested-by: John Garry <john.g.garry@oracle.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230711110214.25093-1-jani.nikula@intel.com

drm/i915/vdsc: Remove FIXME in intel_dsc_compute_config

Remove the FIXME and the code related to it as after verification
it does seem the previous values were typos and no hardware spec
mentions using these particular rc_params.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230626130555.2391750-1-suraj.kandpal@intel.com

drm/i915/dsc: Add rc_range_parameter calculation for YCbCr420

Some rc_range_parameter calculations were missed for YCbCr420,
add them to calculate_rc_param()

--v2
-take into account the new formula to get bpp_i

--v4
-Fix range_bpg_offset formula for YCbCr420 bpp <= 16 [Ankit]

--v5
-Fix comment and mention use of DSC C Model [Ankit]

Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230710162456.2736949-1-suraj.kandpal@intel.com

drm/i915/drm: Fix comment for YCbCr20 qp table declaration

Fix comment for YCbCr420 qp table declaration of max value
where the min value is 4 and the max value is 12/15/18
depending on bpc.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230705051502.2568245-3-suraj.kandpal@intel.com

drm/i915/dsc: Move rc param calculation for native_420

Move rc_param calculation for native_420 into calculate_rc_parameter.
second_line_bpg_offset and second_line_offset_adj are both rc params
and it would be better to have these calculated where all the other
rc parameters are calculated.

--v2
-Add the reason for commit in commit message [Jani]

--v3
-Move nsl_second_line_bpg_offset with the other 420 calculation
in calculate_rc_param [Ankit]

--v4
-Fix comment alignment [Ankit]

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230705051502.2568245-2-suraj.kandpal@intel.com

i915/display/hotplug: use drm_kms_helper_connector_hotplug_event()

This adds more information to the hotplug uevent and lets user-space
know that it's about a particular connector only.

v2: don't rely on the changed HPD pin bitmask to count changed
    connectors (Jani)

Signed-off-by: Simon Ser <contact@emersion.fr>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230623094229.120264-1-contact@emersion.fr

drm/i915: Don't rely that 2 VDSC engines are always enough for pixel rate

We are currently having FIFO underruns happening for kms_dsc test case,
problem is that, we check if curreny cdclk is >= pixel rate only if
there is a single VDSC engine enabled(i.e dsc_split=false) however if
we happen to have 2 VDSC engines enabled, we just kinda rely that this
would be automatically enough.
However pixel rate can be even >= than VDSC clock(cdclk) * 2, so in that
case even with 2 VDSC engines enabled, we still need to tweak it up.
So lets compare pixel rate with cdclk * VDSC engine count and
check if it still requires bumping up.
Previously we had to bump up CDCLK many times for similar reasons.

v2: - Use new intel_dsc_get_num_vdsc_instances to determine number of VDSC
      engines, instead of slice count(Ankit Nautiyal)
v3: - s/u8/int/ (Jani Nikula)
v4: - Remove slice count mentions(Ankit Nautiyal)
    - Use DIV_ROUND_UP in order to make sure that resulting CDCLK would
      be always >= than required, after division(Ankit Nautiyal)

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230704131758.14024-3-stanislav.lisovskiy@intel.com

drm/i915: Add helper function for getting number of VDSC engines

Currently we are using dsc_split and bigjoiner variables for determining
amount of VDSC instances, however that might change in future, if we happen
to have more of those.
So lets pack all that logic into single function for convenience, so that
at least this isn't hardcoded throughout the whole VDSC code.

v2: - s/u8/int/ (Jani Nikula)

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230704131758.14024-2-stanislav.lisovskiy@intel.com

drm/i915: Try to initialize DDI/ICL+ DSI ports for every VBT child device

Try to deal with duplicate child devices for the same DDI port
by attempting to initialize them in VBT defined order The first
on to succeed for a specific DDI port will be the one we use.

We'll also get rid of i915->display.vbt.ports[] here as any conflicts
will now be handled at encoder registration time rather than during
VBT parsing. Note that intel_bios_encoder_data_lookup() still remaims
for pre-DDI DP/HDMI ports as those don't (at least yet) use VBT
driven initialization.

TODO: DSI dual link handling is sketchy at best

v2: Leave intel_bios_encoder_port() to the encoder callback (Jani)

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

drm/i915/bios: Extract intel_bios_encoder_port()

We'll have a few places where we need to do the full (incl. ICL+ DSI)
DVO port->port conversion, so extract the code for that into a helper.

Suggested-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/20230630155846.29931-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Remove AUX CH sanitation

Stop with the VBT AUX CH sanitation, and instead just check
that the appropriate AUX CH is still available when initializing
a DP/TC port.

The reason being that we want to start initializing ports in
VBT order to deal with VBTs that declare child devices with
seemingly conflicting ports. As the encoder initialization can
fail for other reasons (at least for eDP+AUX) we can't know
upfront which way the conflicts should be resolved.

Note that the old way of sanitizing gave priority to the last
port declared in the VBT, but now we sort of do the opposite by
favoring the first encoder to successfully initialize. The reason
for the old "last port wins" preference was eg. Asrock B250M-HDV
where port A (eDP) and port E (DP->VGA) have an AUX CH conflict
and we need to prefer port E. However with the new way port A (eDP)
will be probed first, but will fail to probe due to HPD and thus
port E will still win in the end.

v2: Pimp the commit message (Jani)

Reviewed-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/20230630155846.29931-5-ville.syrjala@linux.intel.com

drm/i915: Remove DDC pin sanitation

Stop with the VBT DDC pin sanitation, and instead just check
that the appropriate DDC pin is still available when initializing
a HDMI connector.

The reason being that we want to start initializing ports in
VBT order to deal with VBTs that declare child devices with
seemingly conflicting ports. As the encoder initialization can
fail for other reasons (at least for eDP+AUX) we can't know
upfront which way the conflicts should be resolved.

Note that the old way of sanitizing gave priority to the last
port declared in the VBT, but now we sort of do the opposite by
favoring the first encoder to successfully initialize. So far
we're not aware of HDMI/DDC use cases where this would matter
but for AUX CH (will be subject to a similar change) there are
known cases where it matters.

Also note that the old code fell back to the platform default DDC
pin if the VBT pin was populated but invalid. That doesn't seem like
such a great idea because the VBT might have later declared another
port using that platform default pin, and so we might just be
creating more DDC pin conflicts here. So lets not second guess the
VBT and simply reject the entire HDMI encoder if the VBT DDC pin is
invalid.

v2: Pimp the commit message (Jani)

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

drm/i915: Only populate aux_ch if really needed

Mixing VBT based AUX CH with platform defaults seems like
a recipe for conflicts. Let's only populate AUX CH if we
absolutely need it, that is only if we are dealing with
a DP output or a TC port (which need it due to some power
well shenanigans).

TODO: double check that real VBTs do in fact populate
      the AUX CH for HDMI TC legacy ports...

Reviewed-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/20230630155846.29931-3-ville.syrjala@linux.intel.com

drm/i915: Initialize dig_port->aux_ch to NONE to be sure

Make sure dig_port->aux_ch is trustworthy by initializing it
to NONE (-1) at the start. The encoder init will later fill in
the actual value, if appropriate.

Reviewed-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/20230630155846.29931-2-ville.syrjala@linux.intel.com

drm/i915: Fail if DSC compression requirement is less than platform supports

Currently we just clamp that value to the highest supported one, however that
means, we are not able to fit this into our available bandwidth range, so we
might see glitches or FIFO underruns.
While choosing less compressed bpp than min bpp required to handle the mode is
harmless and might even save some bandwidth, choosing higher compressed bpp than
min bpp required to handle the required mode config, can cause issues.
So in that case lets just conclude that even with DSC, we are not able to comply
with bandwidth requirements and fail.

v2: - s/clamp_t/min_t/ (Luca Coelho)

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230629122534.8815-1-stanislav.lisovskiy@intel.com

drm/i915/dram: replace __raw_uncore_read32() with intel_uncore_read_fw()

The __raw_uncore_* interface is supposed to be intel_uncore.[ch]
internal only. Replace the remaining outside user with
intel_uncore_read_fw(), which is essentially the same thing.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230627105849.274263-1-jani.nikula@intel.com

drm/i915/uncore: add intel_uncore_regs() helper

Add a helper for accessing uncore->regs instead of doing it
directly. This will help display code reuse with the xe driver.

Cc: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230627095128.208071-1-jani.nikula@intel.com

drm/i915: Don't preserve dpll_hw_state for slave crtc in Bigjoiner

If we are using Bigjoiner dpll_hw_state is supposed to be exactly
same as for master crtc, so no need to save it's state for slave crtc.

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: 0ff0e219d9b8 ("drm/i915: Compute clocks earlier")
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230628141017.18937-1-stanislav.lisovskiy@intel.com

drm/i915: make device info a const pointer to rodata

Finally we can get rid of the pseudo-const write-once device info, and
convert it into a const pointer to device info in rodata.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f31933222f44e4a9224e41399a96896eb243e653.1687878757.git.jani.nikula@intel.com

drm/i915: move display device and runtime info to struct intel_display

Continue moving all things display further into display files and
structures.

v2: Sort includes (Matt)

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fc9ad69a0c7fa972380c654c3b80070ce2f4bf0f.1687878757.git.jani.nikula@intel.com

drm/i915: fix display info usage

Prefer DISPLAY_INFO() over INTEL_INFO()->display.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a61f20726138b8eb77b02e0da70d831c297ab8aa.1687878757.git.jani.nikula@intel.com

drm/i915: separate display info printing from the rest

Add new function intel_display_device_info_print() and print the display
device info there instead of intel_device_info_print(). This also fixes
the display runtime info printing to use the actual runtime info instead
of the static defaults.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/30d4f93c58839bc9312b43423cd43bc0ef655a35.1687878757.git.jani.nikula@intel.com

drm/i915: move platform_engine_mask and memory_regions to device info

The mock device creation was the only place that needed to modify
platform_engine_mask and memory_regions runtime. With mock_info in place
for mock devices, we can move them to device info.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2083fb26468eef13defb9b70523f7f707fc93bad.1687878757.git.jani.nikula@intel.com

drm/i915: use mock device info for creating mock device

Instead of modifying the device info on the fly, use static const mock
device info.

It's not okay to modify device info at runtime; we've added separate
runtime info for info that needs to be modified at runtime. We've added
safeguards to device info to prevent it from being modified, but commit
5e352e32aec2 ("drm/i915: preparation for using PAT index") just cast the
const away and modified it anyway. This prevents device info from being
moved to rodata.

Fixes: 5e352e32aec2 ("drm/i915: preparation for using PAT index")
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Fei Yang <fei.yang@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b0db62045a96a3fd4cf123685da88cc777f9b485.1687878757.git.jani.nikula@intel.com

drm/i915: Remove prototype for intel_cx0_phy_ddi_vswing_sequence()

That function is not defined anywhere.

Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230613214658.1099759-1-gustavo.sousa@intel.com

drm/i915: fix Sphinx indentation warning

Fix Sphinx warning about unexpected indent.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230621123156.14907-2-jani.nikula@intel.com

drm/doc: fix duplicate declaration warning

We have duplicate kernel-doc directives for the same struct, leading to:

/home/jani/src/linux/Documentation/gpu/driver-uapi.rst:2279: WARNING: Duplicate C declaration, also defined at rfc/i915_scheduler:3.
Declaration is '.. c:struct:: i915_context_engines_parallel_submit'.

Use the Sphinx C domain namespace for the rfc document to fix this.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230621123156.14907-1-jani.nikula@intel.com

drm/i915: Prevent needless toggling of DC states during modesets

DC states are disabled / re-enabled around each modeset, which may lead
to a needless off->on->off toggling of the DC_off power well. This has
some overhead as toggling DC states involves running a DMC firmware
handler and also running a periodic firmware handler while DC states are
enabled. The limit of when DC states have a benefit is at 30 FPS (using
DC3co) and below 30 FPS (using DC5/6), where the firmware can actually
disable clocks / power off power wells. Accordingly delay powering off
the DC_off powerwell (which re-enables DC states) by 17 ms at the end of
a modeset to avoid the above overhead at or above 60 FPS.

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616185104.2502003-4-imre.deak@intel.com

drm/i915: Add way to specify the power-off delay of a display power domain

Add support for specifying a delay different than the current 100 ms
default for powering off a display power domain. This is needed by the
next patch which delays re-enabling DC states during modesets to avoid
the off->on->off toggling overhead of the DC_off power well, but does
this using a < 100 ms delay for a better utilization of DC power saving
states.

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616185104.2502003-3-imre.deak@intel.com

drm/i915: Remove redundant forward declarations from display power headers

Remove the forward declarations for enums and structs from display power
header files that aren't used in prototypes.

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616185104.2502003-2-imre.deak@intel.com

drm/i915: Add missing forward declarations/includes to display power headers

Add the seq_file struct forward declaration to intel_display_power.h
fixing the build error below. While at it add the rest of missing
forward declarations/includes to the display power header files.

In file included from <command-line>:
./../drivers/gpu/drm/i915/display/intel_display_power.h:255:70: error: 'struct seq_file'
declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
  255 | void intel_display_power_debug(struct drm_i915_private *i915, struct seq_file *m);
      |                                                                      ^~~~~~~~

Closes: https://lore.kernel.org/intel-gfx/89adc1ac-25a0-6eb6-4cc9-ab6cc8d49730@infradead.org/
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616185104.2502003-1-imre.deak@intel.com

drm/i915/hdcp: Add a debug statement at hdcp2 capability check

Add a debug statement at hdcp2 capability check which indicates if
GSC CS is causing hdcp2 incapability

--v2
-correcttypo in commit header

--v3
-correct the other typo in commit header [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230621085453.1996166-1-suraj.kandpal@intel.com

drm/i915/hdcp: Assign correct hdcp content type

Currently hdcp->content_type is being assigned the content_type field
in drm_connector_state which is wrong and instead it needs to be
assigned hdcp_content_type field from drm_connector_state

Fixes: 4c4279a8d58d ("drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function")
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230622083254.2057102-1-suraj.kandpal@intel.com

drm/i915/psr: Use hw.adjusted mode when calculating io/fast wake times

Encoder compute config is changing hw.adjusted mode. Uapi.adjusted mode
doesn't get updated before psr compute config gets called. This causes io
and fast wake line calculation using adjusted mode containing values before
encoder adjustments. Fix this by using hw.adjusted mode instead of
uapi.adjusted mode.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8475
Fixes: cb42e8ede5b4 ("drm/i915/psr: Use calculated io and fast wake lines")
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230620111745.2870706-1-jouni.hogander@intel.com

drm/i915/mtl: Skip using vbt hdmi_level_shifter selection on MTL

The hdmi_level_shifter part of General Bytes definition in VBT, which was
used for choosing different levels on earlier platforms is now a hidden
optin and shows the default value of 0. The level shifter is now to be
deduced from hdmi_default_entry in  intel_ddi_buf_trans for each phy.

Skip providing the default hw provided value to force driver to choose hdmi
default entry.

Bspec: 20124
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616210028.1601533-1-radhakrishna.sripada@intel.com

drm/i915/mtl: Fix SSC selection for MPLLA

Driver does not clear the default SSC for MPLLA. This causes link training
failure when trying to use 10G and 20G rates. Fix the behaviour and enable
ssc only when we really want.

Fixes: 237e7be0bf57 ("drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA")
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Cc: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616043950.1576836-1-radhakrishna.sripada@intel.com

drm/i915/mtl: Add new vswing table for C20 phy to support DP 1.4

Add vswing table to support DP 1.4 for C20 phy.

v2: rename mtl_c10_trans
v3: add default_entry for mtl_c20_trans_dp14
v4: rename mtl_cx0_trans_dp14

Bspec: 74104
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609002038.11516-1-shawn.c.lee@intel.com

drm/i915/mtl: update DP 2.0 vswing table for C20 phy

Update preset 15 setting to align the latest bspec value.

Bspec: 74104
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230606104238.31953-1-shawn.c.lee@intel.com

drm/i915: Convert HSW/BDW to use port_mask for DDI probe

Make HSW/BDW use port_mask for output probing as well.
To achieve that the strap checks are moved into
intel_ddi_init() itself. Or should we move them to the
runtime port_mask init instead? Maybe not since the hardware
is still there, just not connected to anything.

v2: Account for DDI-E in strap detection
    Keep to the old CRT->DDI init order

Reviewed-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/20230616140820.11726-8-ville.syrjala@linux.intel.com

drm/i915: Init DDI outputs based on port_mask on skl+

Instead of listing every platform's possible DDI outputs
in intel_setup_outputs() just loop over the new port_mask
to achieve the same thing.

HSW/BDW were left as is since they still look at the straps
as well.

DSI is still a mess. For now just check for the relevant
platforms explicitly.

Reviewed-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/20230616140820.11726-7-ville.syrjala@linux.intel.com

drm/i915: Beef up SDVO/HDMI port checks

The SDVO code already warns when the port in question doesn't
actually support SDVO. Let's make that also bail the encoder
registration like the generic assert_port_valid() we added.

And add a similar thing for g4x HDMI, mainly because on g4x
itsefl port D only supports DP but not SDVO/HDMI. For the
other platforms the generic port_mask check should actually
be sufficient, but since we're here might as well list the
ports.

Reviewed-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/20230616140820.11726-6-ville.syrjala@linux.intel.com

drm/i915: Assert that the port being initialized is valid

Sprinkle some asserts to catch any mishaps in the port_mask
vs. output init.

For DDI/DP/HDMI/SDVO I decided that we want to bail out for
an invalid port since those are the encoder types where
we might want consider driving the whole thing from the VBT
child device list, and bogus VBTs could be a real issue
(if for no other reason than the i915.vbt_firmware).

For DVO and HSW/BDW CRT port I just threw the assert in
there for good measure.

Reviewed-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/20230616140820.11726-5-ville.syrjala@linux.intel.com

drm/i915: Assert that device info bitmasks have enough bits

Sprinkle in some BUILD_BUG_ON()s to make sure some of
the bitmasks used in the device info have enough bits.

Do we have a better place for this sort of stuff?

v2: Relocate to the new place

Reviewed-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/20230616140820.11726-4-ville.syrjala@linux.intel.com

drm/i915: Introduce device info port_mask

Declare the available DVO/SDVO/HDMI/DP/DDI ports in the
device info. The other outputs (LVDS/TV/DSI/VGA) are left
out since for most of them we don't consider them as "ports".

DSI we should probably perhaps include somehow in the device
info. Just not sure how. Or we just introduce a HAS_DSI() and
call it a day?

TODO: figure out what to do about the subplatform stuff. Would
      it be better to declare those directly with a different
      device info or not? Also not sure the icl port-f stuff
      matters even. Bspec claims there are icl SKUs with far
      less ports than that and we don't seem to check for those
      either?

v2: Fix TC5 vs. TC6 mixup on TGL (Jani)
    Drop DDI C for now on TGL, and add a FIXME (Jani)

Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616140820.11726-3-ville.syrjala@linux.intel.com

drm/i915: Remove bogus DDI-F from hsw/bdw output init

HSW/BDW don't have DDI-F so don't go looking for one.

Seems to have been accidentally left behind when the
skl+ stuff got split out in commit 097d9e902068
("drm/i915/display: remove strap checks from gen 9").

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616140820.11726-2-ville.syrjala@linux.intel.com

drm/i915/adlp+: Allow DC states along with PW2 only for PWB functionality

A recent bspec update added a restriction on when DC states can be enabled:

[Before enabling DC states:]

"""
PG2 can be kept enabled only because PGB requires PG2.
Do not use PG2 functions, such as type-C DDIs.

DMC will dynamically control PG1, PGA, PG2, PGB.
"""

Accordingly prevent DC states if PW2 (aka PG2) is enabled for any other
functionality.

Bpsec: 49193

Fixes: 88c487938414 ("drm/i915: Use separate "DC off" power well for ADL-P and DG2")
Reported-by: Kai Vehmanen <kai.vehmanen@intel.com>
Tested-by: Ambica Pramod <ambica.pramod@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230606172822.1891897-1-imre.deak@intel.com

drm/i915/psr: Re-enable PSR1 on hsw/bdw

All known issues fixed now, so re-enable PSR1 on hsw/bdw.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-14-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Allow PSR with sprite enabled on hsw/bdw

Can't see why we'd want the sprite blocking PSR entry.
Mask it out.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-13-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Don't skip both TP1 and TP2/3 on hsw/bdw

WA 0479 says: "Do not skip both TP1 and TP2/TP3". Let's just
stick the minimum 100us TP2/3 time in there to avoid that.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-12-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Do no mask display register writes on hsw/bdw

hsw/bdw lack the pipe register vs. display register distinction
in their PSR masking capabilities. So to keep our CURSURFLIVE
tricks working we need to just unmask all display register writes
on these platforms. The downside being that any display regitster
(eg. even SWF regs) will cause a PSR exit.

Note that WaMaskMMIOWriteForPSR asks us to mask this on bdw, but
that won't work since we need those CURSURFLIVE tricks. Observations
on actual hardware show that this causes one extra PSR exit ~every
10 seconds, which is pretty much irrelevant. I suspect this is
due to the pcode poking at IPS_CTL. Disabling IPS does not stop it
however, so either I'm wrong or pcode pokes at the register
regardless of whether it's actually trying to enable/disable IPS.
Also when the machine is busy (eg. just running 'find /') these
extra PSR exits cease, which again points at pcode or some other
PM entity as being the culprit.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-11-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Implement WaPsrDPRSUnmaskVBlankInSRD:hsw

Bspec asks us to unmask "vblank to registers" in the DPRS unit.

Note that I was unable to observe any change in hardware
behviour due to this bit on HSW. But let's do this anyway
in case it matters in some cases, and the corresponding bit
on BDW is abolutely critical as without it the hardware
won't generate any vblanks whatsoever after PSR exit.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-10-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Implement WaPsrDPAMaskVBlankInSRD:hsw

Implement WaPsrDPAMaskVBlankInSRD:hsw, which makes the hardware
generate the extra vblank between link training and first frame
being transmitted. This is the same thing that's controlled by
TRANS_CHICKEN[21] on skl+ (but due to the funky double buffering
it's effectively always at the rest value after DC5 exit). So
for consistent behaviour we want every platform to generate said
vblank. BDW is already setting this up correctly.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-9-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Restore PSR interrupt handler for HSW

Add the PSR interrupt handling code back for HSW. Looks like
the removal was never completed anyway since the irq setup
code was lest untouched.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-8-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: HSW/BDW have no PSR2

Deal with HSW/BDW in transcoder_has_psr2().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-7-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Bring back HSW/BDW PSR AUX CH registers/setup

Reintroduce the special PSR AUX CH setup for hsw/bdw. Not all
of it was even removed (BDW AUX data registers were left behind).
Update the code to use REG_BIT() & co. while at it.

v2: Define the SRD_AUX_CTL bits in terms of DP_AUX_CTL bits (Jouni)
    Add a comment explaining the hand rolled DPCD write (Jouni)

Cc: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-6-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Reintroduce HSW PSR1 registers

Add back hsw'w special SRD/PSR1 registers.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-5-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Wrap PSR1 register with functions

In preparation for re-introducing HSW's different PSR1 register
offeets let's just wrap all the registers into functions.
Avoids having to make the register macros more complex.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-4-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Fix BDW PSR AUX CH data register offsets

The multiplication got replaced by an addition in some cleanup.
This means we never write the correct data to some of the BDW
PSR data registers and thus we fail to actually wake up the
panel from PSR.

Fixes: 4ab4fa103217 ("drm/i915/psr: Make PSR registers relative to transcoders")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-3-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Re-init clock gating on coming out of PC8+

PC8+ clobbers a bunch of displays registers which need to
be restored by hand or else we lost a bunch of workarounds.
The important ones for us are at least CHICKEN_PAR2* and
CHICKEN_PIPESL*.

Curiously at least some CHICKEN_PAR1* registers
are preserved by the hardware/firmware. Unfortunately Bspec
doens't really specify what gets clobbered vs. preserved
so further reverse engieering might be warranted to figure
out the specifics.

Note that PCH_LP_PARTITION_LEVEL_DISABLE is also set by
lpt_init_clock_gating() so the rmw in hsw_disable_pc8()
is now redundant. Remove it.

TODO: I suspect most gt stuff doesn't need this and we should
      finish moving all of them from init_clock_gating() to
      a more appropriate place...

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-2-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/mtl: Cleanup usage of phy lane reset

From PICA message bus we wait for acknowledgment from
read/write commands. In case of an error, we reset the
bus for the next command.

Current implementation ends up resetting message bus twice
in cases where error is not the timeout. Since, we only need
to reset message bus once, let's move reset to corresponding
timeout error and drop the excess reset function calls from
read/write functions.

Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609122130.69794-1-mika.kahola@intel.com

drm/i915/hdcp: Modify hdcp_gsc_message msg sending mechanism

Allocate a multipage object that can be used for input
and output for intel_hdcp_gsc_message so that corruption of
output message can be avoided by the current overwriting method.
Modify intel_gsc_send_sync() to take into account header_out
and addr_out so as to use them to verify the message send status.
Check link for comment and review history
https://patchwork.freedesktop.org/series/118499/

--v2
-Change approach from allocating two objects to just one multipage
object [Daniele]

--v3
-Squash the two patches together [Daniele]
-No need to allocate twice the size of intel_hdcp_gsc_message [Daniele]

Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230602105113.1791104-1-suraj.kandpal@intel.com

drm/i915/dsi: Remove weird has_pch_encoder asserts

No idea why the DSI code is feeling the need to assert that
has_pch_encoder must not be set. PCH encoders aren't even a
thing on any platform that has DSI.

Reviewed-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/20230608203057.23759-14-ville.syrjala@linux.intel.com

drm/i915/dsi: Grab the crtc from the customary place

The encoder hooks already get passed the crtc state so just
grab the crtc from there instead of from the connector state.
This is generally what everyone else does, so no reason for
icl_dsi.c to be different.

Reviewed-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/20230608203057.23759-13-ville.syrjala@linux.intel.com

drm/i915/dsi: Move panel reset+power off to be the last thing

Follow what Windows does and do the DSI panel reset+power off
after everything else.

v2: s/intel_dsi_msleep/msleep/

Reviewed-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/20230608203057.23759-12-ville.syrjala@linux.intel.com

drm/i915/dsi: Respect power_off_delay on icl+

icl+ DSI isn't respecting the panel power_off_delay. Remedy that.

Reviewed-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/20230608203057.23759-11-ville.syrjala@linux.intel.com

drm/i915/dsi: Do DSC/scaler disable earlier on icl+

Do the scaler disable in the spot where bspec has specfied it
for TGL+. And also move the DSC disable to match what
intel_ddi.c does.

Reviewed-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/20230608203057.23759-10-ville.syrjala@linux.intel.com

drm/i915/dsi: Move most things from .disable() into .post_disable() on icl+

encoder->disable() is supposed to happen before the pipe/transcoder
gets disabled. The icl+ DSI code screwed that up and put most things
(including the transcoder disable itself) into  encoder->disable().
Follow the common rules and hoist most things into the
encoder->post_disable() hook.

Reviewed-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/20230608203057.23759-9-ville.syrjala@linux.intel.com

drm/i915/dsi: Implement encoder->shutdown() for icl+

Plug in the encoder->shutdown() hook for icl+ DSI so that
we are guaranteed to respect the power cycle delay during
reboots and whatnot.

Reviewed-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/20230608203057.23759-8-ville.syrjala@linux.intel.com

drm/i915/dsi: Respect power cycle delay on icl+

Handle the DSI panel power cycle delay on icl+.

Reviewed-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/20230608203057.23759-7-ville.syrjala@linux.intel.com

drm/i915/dsi: Gate DSI clocks earlier

The clock gating step is in the wrong spot compared to the
TGL+ bspec sequence. Move it the right place. Windows also
seems to use the TGL+ order here always.

Reviewed-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/20230608203057.23759-6-ville.syrjala@linux.intel.com

drm/i915/dsi: Split icl+ D-PHY vs. DSI timing steps

The programming of the DPHY vs. DSI _TIMING registers are
two separate steps in the TGL+ bspec sequence, with some
other stuff in between. Implement the same split.
Windows also seems follow the bspec TGL+ sequence, even
on ICL/JSL.

Reviewed-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/20230608203057.23759-5-ville.syrjala@linux.intel.com

drm/i915/dsi: Print the VBT MIPI sequence delay duration

Help out debugging things by printing out how long the VBT
delay sequence is supposed to wait.

Reviewed-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/20230608203057.23759-4-ville.syrjala@linux.intel.com

drm/i915/dsi: Do display on sequence later on icl+

Doing the init OTP and display on DSI sequences back to back
doesn't really make any sense (a single sequence would suffice
then). Move the display on sequence to be done just before
backlight on, which is also what Windows does.

Reviewed-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/20230608203057.23759-3-ville.syrjala@linux.intel.com

drm/i915/dsi: Do panel power on + reset deassert earlier on icl+

Looks like we're trying to talk to the DSI panel even before turning
it on, on icl+. Bspec doesn't actually specify when these should be
done, but certainly we need to turn the panel on at least before
talking to it. So let's move the power on + reset deassert steps to
be the first thing we do. This is also what Windows does.

v2: s/intel_dsi_msleep/msleep/

Reviewed-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/20230608203057.23759-2-ville.syrjala@linux.intel.com

drm/i915/gmch: avoid unused variable warning

When CONFIG_PNP is disabled, the mchbar_addr variable is only written but
not read:

drivers/gpu/drm/i915/soc/intel_gmch.c: In function 'intel_alloc_mchbar_resource':
drivers/gpu/drm/i915/soc/intel_gmch.c:41:13: error: variable 'mchbar_addr' set but not used [-Werror=unused-but-set-variable]
   41 |         u64 mchbar_addr;
      |             ^~~~~~~~~~~

No idea why this showed up now, but it's easy to fix by changing the #ifdef to
an IS_ENABLED() check that the compiler can see through.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230612124408.521325-1-arnd@kernel.org

Merge drm/drm-next into drm-intel-next

Sync up with changes from drm-intel-gt-next.

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

drm/i915/selftests: add local workqueue for SW fence selftest

Instead of using a global workqueue for the SW fence selftest,
allocate a separate one temporarily only while running the test.

Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/313f4a713053c2b4896ced5b0e9ff456eb85fe57.1686231190.git.jani.nikula@intel.com

drm/i915: add a dedicated workqueue inside drm_i915_private

In order to avoid flush_scheduled_work() usage, add a dedicated
workqueue in the drm_i915_private structure.  In this way, we don't
need to use the system queue anymore.

This change is mostly mechanical and based on Tetsuo's original
patch[1].

v6 by Jani:
- Also create unordered_wq for mock device

Link: https://patchwork.freedesktop.org/series/114608/
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c816ebe17ef08d363981942a096a586a7658a65e.1686231190.git.jani.nikula@intel.com

drm/i915: use pointer to i915 instead of rpm in wakeref

Currently a pointer to an intel_runtime_pm structure is stored in the
wake reference structures so the runtime data can be accessed.  We can
save the entire device information (drm_i915_private) instead, since
we'll need to reference the new workqueue we'll add in subsequent
patches.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ec0eb5149120d04f3d9870d7671ef10103e6fc29.1686231190.git.jani.nikula@intel.com

Merge tag 'drm-intel-gt-next-2023-06-08' of git://anongit.freedesktop.org/drm/drm-intel into drm-next

UAPI Changes:

- I915_GEM_CREATE_EXT_SET_PAT for Mesa on Meteorlake.

Driver Changes:

Fixes/improvements/new stuff:

- Use large rings for compute contexts (Chris Wilson)
- Better logging/debug of unexpected GuC communication issues (Michal Wajdeczko)
- Clear out entire reports after reading if not power of 2 size (Ashutosh Dixit)
- Limit lmem allocation size to succeed on SmallBars (Andrzej Hajda)
- perf/OA capture robustness improvements on DG2 (Umesh Nerlige Ramappa)
- Fix error code in intel_gsc_uc_heci_cmd_submit_nonpriv() (Dan Carpenter)

Future platform enablement:

- Add workaround 14016712196 (Tejas Upadhyay)
- HuC loading for MTL (Daniele Ceraolo Spurio)
- Allow user to set cache at BO creation (Fei Yang)

Miscellaneous:

- Use system include style for drm headers (Jani Nikula)
- Drop legacy CTB definitions (Michal Wajdeczko)
- Turn off the timer to sample frequencies when GT is parked (Ashutosh Dixit)
- Make PMU sample array two-dimensional (Ashutosh Dixit)
- Use the correct error value when kernel_context() fails (Andi Shyti)
- Fix second parameter type of pre-gen8 pte_encode callbacks (Nathan Chancellor)
- Fix parameter in gmch_ggtt_insert_{entries, page}() (Nathan Chancellor)
- Fix size_t format specifier in gsccs_send_message() (Nathan Chancellor)
- Use the fdinfo helper (Tvrtko Ursulin)
- Add some missing error propagation (Tvrtko Ursulin)
- Reduce I915_MAX_GT to 2 (Matt Atwood)
- Rename I915_PMU_MAX_GTS to I915_PMU_MAX_GT (Matt Atwood)
- Remove some obsolete definitions (John Harrison)

Merges:

- Merge drm/drm-next into drm-intel-gt-next (Tvrtko Ursulin)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ZIH09fqe5v5yArsu@tursulin-desk

Merge tag 'drm-intel-next-2023-06-05' of git://anongit.freedesktop.org/drm/drm-intel into drm-next

drm/i915 features for v6.5:

Features and functionality:
- Meteorlake (MTL) display enabling (Mika, Radhakrishna, José, Ankit, Clint,
  Gustavo, Imre, Anusha, Juha-Pekka, Matt)
- Allow VRR to be toggled during fastsets (Ville)
- Allow arbitrary refresh rates with VRR eDP panels (Ville)
- Support async flips on linear buffers on display ver 12+  (Arun)
- New debugfs for display clock frequencies (Bhanuprakash)
- Taint kernel when force probing unsupported devices (Jani)
- Expose CRTC CTM property on ILK/SNB/VLV (Ville)

DRM subsystem changes:
- EDID changes to support further conversion to struct drm_edid (Jani)
- Move i915 DSC parameter code to common DRM helpers (Dmitry Baryshkov)

Refactoring and cleanups:
- CSC color refactoring (Ville)
- VRR cleanups (Ville)
- Finish i915 conversion to struct drm_edid (Jani)
- Start high level display driver file (Jani)
- Hotplug refactoring (Ville)
- Misc display refactoring and cleanups (Jani, Ville)
- Use device based logging for state checker warnings (Jani)
- Split out hotplug and display irq handling (Jani)
- Move display device info and probe under display/ (Matt)
- HDCP cleanups (Suraj)
- Use localized warning ignores instead of per file (Jani)
- Remove superfluous enum i915_drm_suspend_mode (Maarten)
- PSR, pfit, scaler and chicken register definition cleanups (Ville)
- Constify pointers to hwmon_channel_info (Krzysztof Kozlowski)
- Replace all non-returning strlcpy with strscpy (Azeem Shaikh)
- Refactor VBT aux channel and DDC pin mapping (Ville)
- Include cleanups (Jani)

Fixes:
- Fix modeset locking issue in DP MST HDCP (Suraj)
- Fix disconnected Type-C/DP-alt disable at probe (Imre)
- Fix HDMI PCON DSC usage and color conversions (Ankit)
- Fix g4x HDMI infoframe/audio transmission port usage (Ville)
- Avoid use-after-free when DP connector init fails (Maarten)
- Fix voltage level for 480 MHz CDCLK (Chaitanya)
- Check HPD live state during eDP probe (Ville)
- Fix active port PLL selection for secondary MST streams (Imre)
- Check pipe source size when using SKL+ scalers (Ville)
- Fix MIPI DSI sleep sequences (Hans de Goede)
- Fix DPCD register write order to match 128b/132b requirement (Arun)
- Increase AUX timeout for Type-C (Suraj)
- Communicate display power demands to pcode (Stan)
- Fix potential division by zero in DSC compute config (Nikita Zhandarovich)
- Fix fast wake AUX sync length (Jouni)
- Fix potential oops on intel_get_crtc_new_encoder() (Ville)

Merges:
- drm-next backmerges (Rodrigo, Jani)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/87zg5eat32.fsf@intel.com

Merge tag 'drm-misc-next-2023-06-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

drm-misc-next for v6.5:

UAPI Changes:

Cross-subsystem Changes:

Core Changes:

Driver Changes:

 * bridge
   * imx: Fix module linking
   * tc358762: Support reset GPIO

 * meson
   * Add support for MIPI DSI displays; plus fixes and DT bindings

 * panel
   * Add Support for Rocktech RK043FN48H; plus DT bindings
   * Add support for Starry himax83102-j02; plus DT bindings
   * Add support for Starry ili9882t; plus DT bindings

 * virtio
   * Support sync-object UAPI

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230607085644.GA12673@linux-uq9g

Merge tag 'drm-habanalabs-next-2023-06-08' of https://git./linux/kernel/git/ogabbay/linux into drm-next

This tag contains additional habanalabs driver changes for v6.5:

- uAPI changes:
  - Return 0 when user queries if there was a h/w or f/w error and no such error happened.
    Previously we returned an error in such case.

- New features and improvements:
  - Add pci health check when we lose connection with the firmware. This can be used to
    distinguish between pci link down and firmware getting stuck.
  - Add more info to the error print when TPC interrupt occur.
  - Reduce amount of code under mutex in the command submission of signal event.

- Firmware related fixes:
  - Fixes to the handshake protocol during f/w initialization.
  - Display information that the f/w sends us when encountering a DMA error.
  - Do soft-reset using a message sent to firmware instead of writing to MMIO.
  - Prepare generic code to extract f/w version numbers.

- Bug fixes and code cleanups. Notable fixes are:
  - Unsecure certain TPC registers that the user should access.
  - Fix handling of QMAN errors
  - Fix memory leak when recording errors (to later pass them to the user)
  - Multiple fixes to razwi interrupt handling code

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Oded Gabbay <ogabbay@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230608103043.GA2699019@ogabbay-vm-u20.habana-labs.com

Merge tag 'drm-next-20230529' of git://git./linux/kernel/git/pinchartl/linux into drm-next

Renesas DRM/KMS drivers:

- Group drivers in renesas subdirectory to prepare for new platform
- Drop deprecated R-Car H3 ES1.x support

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230602111504.GA24855@pendragon.ideasonboard.com

accel/habanalabs: refactor error info reset

Moved error info reset code to single function for future use from
other places in the driver.

Signed-off-by: Dani Liberman <dliberman@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>

accel/habanalabs: add event queue extra validation

In order to increase reliability of the event queue interface,
we apply to Gaudi2 the same mechanism we have in Gaudi1.
The extra validation is basically checking that the received
event index matches the expected index.

Signed-off-by: Ofir Bitton <obitton@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>

accel/habanalabs: unsecure TSB_CFG_MTRR regs

In order to utilize Engine Barrier padding, user must have access to
this register set.

Signed-off-by: Ofir Bitton <obitton@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>

accel/habanalabs: move ioctl error print to debug level

We don't want to allow users to spam the kernel log and sending
ioctls with bad opcodes is a sure way to do it.

Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Reviewed-by: Ofir Bitton <obitton@habana.ai>

accel/habanalabs: fix bug of not fetching addr_dec info

addr_dec info should always be fetched, regardless of cause value.

Signed-off-by: Ofir Bitton <obitton@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>

accel/habanalabs: add description to several info ioctls

Several info ioctls may return success although no data retrieved.

Signed-off-by: Dani Liberman <dliberman@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>

accel/habanalabs: remove sim code

There were a few places where simulator only code got into the upstream.
Remove those places that can confuse other developers.

Fixes: 2a0a839b6a28 ("habanalabs: extend fatal messages to contain PCI info")
Cc: Moti Haimovski <mhaimovski@habana.ai>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>

accel/habanalabs: mask part of hmmu page fault captured address

When receiving page fault from hmmu, the captured address is scrambled
both by HW and by driver. The driver part is unscrambled but the HW
part isn't getting unscrambled.
To avoid declaring wrong address, the HW scrambled part will be
masked.

Signed-off-by: Dani Liberman <dliberman@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>