drm/i915/display: Add CDCLK Support for MTL

As per bSpec MTL has 38.4 MHz Reference clock.
Adding the cdclk tables and cdclk_funcs that MTL
will use.

v2: Revert to using bxt_get_cdclk()

BSpec: 65243

Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221117230002.792096-3-anusha.srivatsa@intel.com

drm/i915/display: Do both crawl and squash when changing cdclk

For MTL, changing cdclk from between certain frequencies has
both squash and crawl. Use the current cdclk config and
the new(desired) cdclk config to construct a mid cdclk config.
Set the cdclk twice:
- Current cdclk -> mid cdclk
- mid cdclk -> desired cdclk

Driver should not take some Pcode mailbox communication
in the cdclk path for platforms that are Display version 14 and later.

v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk
change via modeset for platforms that support squash_crawl sequences(Ville)

v3: Add checks for:
- scenario where only slow clock is used and
cdclk is actually 0 (bringing up display).
- PLLs are on before looking up the waveform.
- Squash and crawl capability checks.(Ville)

v4: Rebase
- Move checks to be more consistent (Ville)
- Add comments (Bala)
v5:
- Further small changes. Move checks around.
- Make if-else better looking (Ville)

v6: MTl should not follow PUnit mailbox communication as the rest of
gen11+ platforms.(Anusha)

Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221117230002.792096-2-anusha.srivatsa@intel.com

drm/i915/display: Add missing checks for cdclk crawling

cdclk_sanitize() function was written assuming vco was a signed integer.
vco gets assigned to -1 (essentially ~0) for the case where PLL
might be enabled and vco is not a frequency that will ever
get used. In such a scenario the right thing to do is disable the
PLL and re-enable it again with a valid frequency.
However the vco is declared as a unsigned variable.
With the above assumption, driver takes crawl path when not needed.
Add explicit check to not crawl in the case of an invalid PLL.

v2: Move the check from .h to .c (MattR)
- Move check to bxt_set_cdclk() instead of
intel_modeset_calc_cdclk() which is directly in
the path of the sanitize() function (Ville)

v3: remove unwanted parenthesis(Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221117230002.792096-1-anusha.srivatsa@intel.com

drm/i915/dvo: Use per device debugs

Convert the lonely DRM_DEBUG_KMS() to the per-device variant.

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

drm/i915/dvo: s/dev_priv/i915/

Follow the modern style and rename most 'dev_priv' variables
to 'i915'.

intel_dvo_init_dev() is the sole exception since it needs the
magic 'dev_priv' variable for the DPLL register macros.

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

drm/i915/dvo: s/intel_encoder/encoder/ etc.

Remove the pointless intel_ namespace from our encoder/connector
variables.

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

drm/i915/dvo: Flatten intel_dvo_init()

The loop over intel_dvo_devices[] makes intel_dvo_init()
an ugly mess. Pull the i2c device probe out to a separate
function so that we can get rid of the loop and flatten
the code.

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

drm/i915/dvo: Eliminate useless 'port' variable

Reorder the drm_encoder_init() vs. encoder->port
assignment so that we don't need the extra 'port'
variable.

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

drm/i915/dvo: Introduce intel_dvo_connector_type()

Introduce intel_dvo_connector_type() as a counterpart to
intel_dvo_encoder_type(), mainly to declutter intel_dvo_init()
a bit.

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

drm/i915/dvo: Actually initialize the DVO encoder type

We call drm_encoder_init() before determining the correct
encoder type, thus we always end up with DRM_MODE_ENCODER_NONE.
Determine the correct encoder type earlier.

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

drm/i915/dvo: Don't leak connector state on DVO init failure

If we can't initialize the DVO encoder also free the connector
state allocated by intel_connector_alloc().

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

drm/i915/dvo: Remove unused panel_wants_dither

intel_dvo.panel_wants_dither is only set but never used.
We can't do dithering on the gmch side anyway since the
dithering logic is part of the integrated LVDS port and
not available for other output types.

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

drm/i915/dg2: Drop force_probe requirement

DG2 has been very usable for a while now, and all of the uapi changes
related to fundamental platform usage have been finalized.  Recent CI
results have also been healthy, so we're ready to drop the force_probe
requirement and enable the platform by default.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221109001328.732000-1-matthew.d.roper@intel.com

drm/i915/mtl: Skip doubling channel numbers for LPDDR4/LPDDDR5

MTL LPDDR5 reported 16b with 8 channels. Previous platforms
reported 32b with 4 channels and hence needed a multiplication
by a factor of 2. Skip increasing the channels for MTL.

v2: Use version check instead of platform check(MattR)

Bspec: 64631
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221117213015.584417-2-radhakrishna.sripada@intel.com

drm/i915/mtl: Fix dram info readout

MEM_SS_INFO_GLOBAL Register info read from the hardware is cached in val. However
the variable is being modified when determining the DRAM type thereby clearing out
the channels and qgv info extracted later in the function xelpdp_get_dram_info. Preserve
the register value and use extracted fields in the switch statement.

Fixes: 825477e77912 ("drm/i915/mtl: Obtain SAGV values from MMIO instead of GT pcode mailbox")
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221117213015.584417-1-radhakrishna.sripada@intel.com

drm/i915/rpl-p: Add stepping info

Add stepping-substepping info in accordance to bpsec changes.

Bspec: 55376

Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221117214132.152061-1-matthew.s.atwood@intel.com

drm/i915/mtl+: Don't enable the AUX_IO power for non-eDP port main links

MTL+ requires the AUX_IO power for the main link only on eDP, so don't
enable it in other cases.

v2:
- Rebased on checking intel_encoder_can_psr() instead of crtc->has_psr.

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/20221114122251.21327-10-imre.deak@intel.com

drm/i915: Factor out function to get/put AUX_IO power for main link

Factor out functions to get/put the AUX_IO power domain for the main
link on DDI ports.

While at it clarify the corresponding code comment.

No functional change.

v2:
- s/(get/put)_aux_power_for_main_link/main_link_aux_power_domain_(get/put)
  (Jani)
- Clarify in the code comment that AUX_IO is needed only by TypeC besides
  eDP/PSR.
v3:
- Rebased on checking intel_encoder_can_psr() instead of crtc->has_psr.
v4:
- Don't call fetch_and_zero() with side-effect during variable
  declaration. (Ville)

Cc: Jani Nikula <jani.nikula@intel.com>
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/20221114122251.21327-9-imre.deak@intel.com

drm/i915: Add missing DC_OFF power domain->well mappings

Add the missing DC_OFF power domain -> DC_OFF power well mappings on all
platforms. This didn't cause a problem as the DC_OFF power domain is
only used on JSL, where the mapping was already correct.

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/20221114122251.21327-8-imre.deak@intel.com

drm/i915: Add missing AUX_IO_A power domain->well mappings

BXT and GLK were missing the AUX_IO_A power domain -> PHY A common power
well mapping, add these now. This didn't cause a problem as the
AUX_IO_A and DDI_LANES_A power domains are acquired together.

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/20221114122251.21327-7-imre.deak@intel.com

drm/i915/tgl+: Enable display DC power states on all eDP ports

Starting with TGL eDP is supported on ports B+ (besides port A), so make
sure DC states are not blocked on any such ports. For this add an
AUX_IO_<port> power domain for each port with eDP support. These domains
similarly to AUX_IO_A enable only the AUX_IO_<port> power well for an
enabled port, whereas the existing AUX_<port> domains enable both the
AUX_IO_<port> and the DC_OFF power wells as required by DP AUX transfers.

v2: (Ville)
- Split the change using AUX vs. AUX_IO on port A to a separate patch.
- Select AUX_IO vs. AUX based on crtc_state->has_psr instead of
  is_edp().
v3:
- Rebased on checking intel_encoder_can_psr() instead of crtc->has_psr.
v4:
- Fix warn in intel_display_power_aux_io_domain(). (Ville)

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/20221114122251.21327-6-imre.deak@intel.com

drm/i915: Use the AUX_IO power domain only for eDP/PSR port

Use the AUX_IO_A display power domain only for eDP on port A where PSR
is also supported. This is the case where DC states need to be enabled
while the output is enabled - ensured by AUX_IO_A domain not enabling
the DC_OFF power well. Otherwise port A can be treated the same way as
other ports with an external DP output: using the AUX_<port> domain
which disables the unrequired DC states.

This change prepares for the next patch enabling DC states on all ports
supporting eDP/PSR besides port A.

v2:
- Check the encoder PSR capability instead of PSR being enabled in the
  crtc_state, as the latter can be changed with a fastset.

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/20221114122251.21327-5-imre.deak@intel.com

drm/i915: Move the POWER_DOMAIN_AUX_IO_A definition to its logical place

Move the definition of the AUX_IO_A power domain, requiring only the
corresponding AUX_IO_A power well to be enabled, before all the
AUX_<port> power domains, which require both the AUX_IO_<port> and the
DC_OFF power wells to be enabled.

No functional change.

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/20221114122251.21327-4-imre.deak@intel.com

drm/i915: Preallocate the debug power domain wakerefs array

Since the current size of intel_display_power_domain_set struct is
close to 1kB, it's better to use preallocated memory for it. The only
user of the intel_display_power_get/put_in_set() allocating the struct
on stack is hsw_get_pipe_config(), so we can avoid potential stack
overallocations by moving the struct here to the preallocated
intel_crtc struct (hsw_get_pipe_config() is non-reentrant wrt. each
CRTC).

This patch replaces
https://lore.kernel.org/intel-gfx/20221107170917.3566758-5-imre.deak@intel.com/T/#md3f6cdf17fcd

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@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/20221114122251.21327-3-imre.deak@intel.com

drm/i915: Fix warn in intel_display_power_*_domain() functions

The intel_display_power_*_domain() functions should always warn if a
default domain is returned as a fallback, fix this up. Spotted by Ville.

Fixes: 979e1b32e0e2 ("drm/i915: Sanitize the port -> DDI/AUX power domain mapping for each platform")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jouni Högander <jouni.hogander@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/20221114122251.21327-2-imre.deak@intel.com

drm/i915/audio: Realign some function arguments

Fix up some function argument alignment fails.

Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221108151839.31567-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/audio: Unify get_saved_enc()

Make the two branches of get_saved_enc() look alike. Currently
they look different even though they do exactly the same thing
apart from == vs. != for the MST comparison.

Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221108151839.31567-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Treat HDMI as DVI when cloning

When doing HDMI+non-HDMI cloning the other sink can't get
the infoframes/etc. so stuff like limited range output is
not a good idea.

Similarly when doing HDMI+HDMI cloning on g4x (only platform
where we allow it) only one of the ports can receive infoframes
and so again using any fancy stuff is a bad idea. We also don't
track the inforames/audio state per-port so we'd end up with
some kind of random mismash state when multipled encoders try
to compute the same stuff. And the hardware will in fact
automagically disable audio/infoframe transmission if you try
to enable it for multiple HDMI ports at the same time.

Thus disable all HDMI specific features when cloning.

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

drm/i915: Force RGB output for DVI sink

YCbCr output requires infoframes and whatnot, so don't allow
it when dealing with a DVI sink (or a HDMI sink we wish to
treat as DVI).

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

drm/i915: Introduce g4x_hdmi_compute_config()

Start pulling some of the more platform specific things out from
intel_hdmi_compute_config(). has_pch_encoder is clearly one
such thing.

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

drm/i915: Reorder 12.4 lut udw vs. ldw functions

Satisfy my ocd and define ilk_lut_12p4_ldw() before ilk_lut_12p4_udw().
That is the order all the other similar functions use.

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

drm/i915: Clean up chv CGM (de)gamma defines

Add the missing ldw vs. udw information to the CGM (de)gamma
bit definitions to make it a bit easier to see which should
be used where.

Also use the these appropriately in the LUT entry pack/unpack
functions.

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

drm/i915: Clean up 12.4bit precision palette defines

Use consistent bit definitions for the 12.4bit precision palette bits.
We just define these alongside the ilk/snb register definitions and
point to those from the icl+ superfine segment defines (and we also
already pointed to them from the ivb+ precision palette defines).

Also use the these appropriately in the LUT entry pack/unpack
functions.

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

drm/i915: Clean up 10bit precision palette defines

Use consistent bit definitions for the 10bit precision palette bits.
We just define these alongside the ilk/snb register definitions and
point to those from the ivb+ defines.

Also use the these appropriately in the LUT entry pack/unpack
functions.

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

drm/i915: Clean up legacy palette defines

Use consistent bit definitions for the legacy gamma LUT. We just
define these alongside the pre-ilk register definitions and point
to those from the ilk+ defines.

Also use the these appropriately in the LUT entry pack/unpack
functions.

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

drm/i915: Add device name to display tracepoints

Include dev_name() in the tracpoints so one can filter based on
the device.

Example:
echo 'dev=="0000:00:02.0"' > events/i915/intel_cpu_fifo_underrun/filter

v2: Reduce the magic macros, rebase

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

drm/i915: Pass i915 to frontbuffer tracepoints

Pass the device to the frontbuffer tracpoints. Will be used
later to include the device name in the tracpoints.

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

drm/i915: Print plane name in fbc tracepoints

Print the name of the plane in the fbc tracepoints. As the
pipe<->plane assignment can vary on old hw it's probably
more helpful to see both the plane and the pipe names together.

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

drm/i915: Pass intel_plane to plane tracepoints

Pass intel_plane rather than drm_plane to the plane tracepoints.
Matches what we do eg. with the fbc tracepoints. Using the same
type for everything will help with digging out the device name
from the plane in the future.

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

drm/i915/display: move restore state and ctx under display sub-struct

Move display suspend/resume and display reset modeset state and ctx
members under drm_i915_private display sub-struct.

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

drm/i915/display: move global_obj_list under display sub-struct

Move display global state member under drm_i915_private display
sub-struct.

Prefer adding anonymous sub-structs even for single members that aren't
our own structs.

Remove a nearby stale comment while at it.

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

drm/i915/display: move hti under display sub-struct

Move display hti/hdport related members under drm_i915_private display
sub-struct.

Prefer adding anonymous sub-structs even for single members that aren't
our own structs.

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

drm/i915/hti: abstract hti handling

The HTI or HDPORT handling is sprinkled around. Centralize to one place.

Add a note about how subtle the mapping from HDPORT_STATE register to
dpll mask actually is.

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

Merge tag 'gvt-next-2022-11-17' of https://github.com/intel/gvt-linux into drm-intel-next

gvt-next-2022-11-17

- kernel doc fixes
- remove vgpu->released sanity check
- small clean up

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221117064106.GT30028@zhen-hp.sh.intel.com

drm/i915/edp: wait power off delay at driver remove to optimize probe

Panel power off delay is the time the panel power needs to remain off
after being switched off, before it can be switched on again.

For the purpose of respecting panel power off delay at driver probe,
assuming the panel was last switched off at driver probe is overly
pessimistic. If the panel was never on, we'd end up waiting for no
reason.

We don't know what has happened before kernel boot, but we can make some
assumptions:

- The panel may have been switched off right before kernel boot by some
  pre-os environment.

- After kernel boot, the panel may only be switched off by i915.

- At i915 driver probe, only a previously loaded and removed i915 may
  have switched the panel power off.

With these assumptions, we can initialize the last power off time to
kernel boot time, if we also ensure i915 driver remove waits for the
panel power off delay after switching panel power off.

This shaves off the time it takes from kernel boot to i915 probe from
the first panel enable, if (and only if) the panel was not already
enabled at boot.

The encoder destroy hook is pretty much the last place where we can
wait, right after we've ensured the panel power has been switched off,
and before the whole encoder is destroyed.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7417
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Lee Shawn C <shawn.c.lee@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221116150657.1347504-1-jani.nikula@intel.com

drm/i915/gvt: Remove the unused function get_pt_type()

The function get_pt_type is defined in the gtt.c file, but not
called elsewhere, so delete this unused function.

drivers/gpu/drm/i915/gvt/gtt.c:285:19: warning: unused function 'get_pt_type'.

Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2277
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220926064044.53016-1-jiapeng.chong@linux.alibaba.com
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915: fix repeated words in comments

Delete the redundant word 'the'.

Signed-off-by: wangjianli <wangjianli@cdjrlc.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20221022061327.65275-1-wangjianli@cdjrlc.com
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/gvt: remove the vgpu->released and its sanity check

The life cycle of a vGPU, which is represented by a vfio_device, has been
managed by the VFIO core logic. Remove the vgpu->released, which was used
for a sanity check on the removal path of the vGPU instance. The sanity
check has already been covered in the VFIO core logic.

Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: intel-gvt-dev@lists.freedesktop.org
Suggested-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20221104145652.1570-1-zhi.a.wang@intel.com
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>

i915/gvt: remove hardcoded value on crc32_start calculation

struct gvt_firmware_header has a crc32 member in which all members that
come after the that field are used to calculate it. The previous
implementation added the value '4' (crc32's u32 size) to calculate the
crc32_start offset which came across as a bit cryptic until you take a
deeper look at the struct.

This patch changes crc32_start offset to the 'version' member which is
the first member of the struct gvt_firmware_header after crc32.

It's worth mentioning that doing a build before/after this patch results
in no binary output differences.

Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20221030033628.GA279284@mail.google.com
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915: gvt: fix kernel-doc trivial warnings

Some functions seem to have been renamed without updating the kernel-doc
markup causing warnings. Also, struct intel_vgpu_dmabuf_obj is not
properly documented, but has a kerneld-doc markup.

Fix those warnings:
drivers/gpu/drm/i915/gvt/aperture_gm.c:308: warning: expecting prototype for inte_gvt_free_vgpu_resource(). Prototype was for intel_vgpu_free_resource() instead
drivers/gpu/drm/i915/gvt/aperture_gm.c:344: warning: expecting prototype for intel_alloc_vgpu_resource(). Prototype was for intel_vgpu_alloc_resource() instead
drivers/gpu/drm/i915/gvt/cfg_space.c:257: warning: expecting prototype for intel_vgpu_emulate_cfg_read(). Prototype was for intel_vgpu_emulate_cfg_write() instead
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'vgpu' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'info' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'dmabuf_id' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'kref' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'initref' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'list' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/handlers.c:3066: warning: expecting prototype for intel_t_default_mmio_write(). Prototype was for intel_vgpu_default_mmio_write() instead
drivers/gpu/drm/i915/gvt/mmio_context.c:560: warning: expecting prototype for intel_gvt_switch_render_mmio(). Prototype was for intel_gvt_switch_mmio() instead
drivers/gpu/drm/i915/gvt/page_track.c:131: warning: expecting prototype for intel_vgpu_enable_page_track(). Prototype was for intel_vgpu_disable_page_track() instead
drivers/gpu/drm/i915/gvt/vgpu.c:215: warning: expecting prototype for intel_gvt_active_vgpu(). Prototype was for intel_gvt_activate_vgpu() instead
drivers/gpu/drm/i915/gvt/vgpu.c:230: warning: expecting prototype for intel_gvt_deactive_vgpu(). Prototype was for intel_gvt_deactivate_vgpu() instead
drivers/gpu/drm/i915/gvt/vgpu.c:358: warning: expecting prototype for intel_gvt_destroy_vgpu(). Prototype was for intel_gvt_destroy_idle_vgpu() instead

Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/375c0c0ca2ef414f25e14f274457f77373a9268d.1657699522.git.mchehab@kernel.org
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"

There is a spelling mistake in a gvt_vgpu_err error message. Fix it.

Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220315202449.2952845-1-colin.i.king@gmail.com
Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915: remove circ_buf.h includes

The last user of macros from that include was removed in 2018 by the
commit below.

Fixes: 6cc42152b02b ("drm/i915: Remove support for legacy debugfs crc interface")
Cc: Jani Nikula <jani.nikula@linux.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>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221115070302.4064-1-jirislaby@kernel.org

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

Catch up on 6.1-rc cycle in order to solve the intel_backlight
conflict on linux-next.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/nouveau/disp: fix incorrect/broken hdmi methods

These are fixes from Lyude, and were meant to have been included in the
last round of drm-next patches.

- Fix some nasty memory issues that broke Lyude's display:
  - 0 initialize both nvif args and parsed HDMI infoframe buffers
  - Fixed missing memset(…, 0, …) for nvif args before sending VSI
    infoframe
  - Fixed incorrect data pointer and size in nvkm_uoutp_mthd_infoframe()
    (was previously pointing at the start of the nvif_outp_infoframe_args
    struct instead of at the start of the infoframe data
- Get rid of duplicated scdc assignments, since we only use it to write the
  scdc registers

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

drm/i915: stop including i915_irq.h from i915_trace.h

Turns out many of the files that need i915_reg.h get it implicitly via
{display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h
-> i915_reg.h. Since i915_trace.h doesn't actually need i915_irq.h,
makes sense to drop it, but that requires adding quite a few new
includes all over the place.

Prefer including i915_reg.h where needed instead of adding another
implicit include, because eventually we'll want to split up i915_reg.h
and only include the specific registers at each place.

Also some places actually needed i915_irq.h too.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
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/6e78a2e0ac1bffaf5af3b5ccc21dff05e6518cef.1668008071.git.jani.nikula@intel.com

drm/i915: split out intel_display_reg_defs.h

Split out the display register helper macros to a separate file. For
now, include it from i915_reg.h, but note that there are already files
that don't need i915_reg.h, such as intel_audio.c.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
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/3af47193ff5219b6d2cfe353b752ec4bb44de4f1.1668008071.git.jani.nikula@intel.com

drm/i915/reg: move pick even and pick to reg defs

This is a more logical place for generic helpers.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
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/623327aee73a515300d99c8d65552ca92f3f0721.1668008071.git.jani.nikula@intel.com

drm/i915/reg: move masked field helpers to i915_reg_defs.h

This is a more logical place for generic helpers.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
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/5161a0c6d98df206c6c4c1add3fc3f2f408020b1.1668008071.git.jani.nikula@intel.com

drm/i915: Create resized LUTs for ivb+ split gamma mode

Currently when opeating in split gamma mode we do the
"skip ever other sw LUT entry" trick in the low level
LUT programming/readout functions. That is very annoying
and a big hinderance to revamping the color management
uapi.

Let's get rid of that problem by making half sized copies
of the software LUTs and plugging those into the internal
{pre,post}_csc_lut attachment points (instead of the sticking
the uapi provide sw LUTs there directly).

With this the low level stuff will operate purely in terms
the hardware LUT sizes, and all uapi nonsense is contained
to the atomic check phase. The one thing we do lose is
intel_color_assert_luts() since we no longer have a way to
check that the uapi LUTs were correctly used when generating
the internal copies. But that seems like a price worth paying.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221026113906.10551-12-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915/display: move struct intel_link_m_n to intel_display_types.h

struct intel_crtc_state in intel_display_types.h actually needs the
struct intel_link_m_n definition, while intel_display.h only needs the
forward declaration.

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

Merge branch '00.06-gr-ampere' of https://gitlab.freedesktop.org/skeggsb/nouveau into drm-next

This is the pull request for a whole bunch of fixes and prep-work that
was done to support Ampere acceleration prior to GSP-RM being
available.  It uses the ACR firmware released by NVIDIA in
linux-firmware, as we do on earlier GPUs.  The work to support running
on top of GSP-RM also heavily depends on various pieces of this
series.

In addition to the new HW support, general stability of the driver
should be improved, especially around recovering HW from bugs that can
be generated by userspace driver components.

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CABDvA==s+nZD0n7CuRWLPE=Pj+02CN13r+ZQJxoHQ_EmR+o=XQ@mail.gmail.com

drm/nouveau/gr/ga102: initial support

v2:
- whitespace

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Gourav Samaiya <gsamaiya@nvidia.com>

drm/nouveau/ltc/ga102: initial support

v2. fixup for ga103 early merge

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/acr/ga102: initial support

v2. fixup for ga103 early merge

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Gourav Samaiya <gsamaiya@nvidia.com>

drm/nouveau/fb/ga102: load and boot VPR scrubber FW

v2. fixup for ga103 early merge

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Gourav Samaiya <gsamaiya@nvidia.com>

drm/nouveau/gr/tu102: remove gv100_grctx_unkn88c

Match RM.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/tu102: add gv100_gr_init_4188a4

Match RM.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/tu102-: fix support for sw_bundle64_init

We weren't sending the high bits, though they're zero currently anyway.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/tu102-: use sw_veid_bundle_init from firmware

NVIDIA provided this on Turing, but we kept using the hardcoded version
from Volta (where they didn't).

Switch to the firmware version prior to Ampere.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gv100-: drop a write from init_shader_exceptions()

Match RM.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gv100-: move init_419bd8() after sw_ctx load

Match RM.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gv100-: add NV_PGRAPH_PRI_PD_AB_DIST_CONFIG_1 to patch list

Match RM.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gv100-: fix number of tile map registers

Match RM.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gv100-: port smid mapping code from nvgpu

Essentially ripped verbatim from NVGPU, comments and all, and adapted to
nvkm's structs and style.

- maybe fixes an nvgpu bug though, a small tweak was needed to match RM

v2:
- remove unnecessary WARN_ON

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gp100-: modify init_fecs_exceptions

Match RM.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gk20a,gm20b,gp10b: split out netlist parsing from fw loading

We'll want to reuse the former for loading from proper netlist images.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gp100-: fix number of zcull tile regs

Match RM.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf117-: make ppc_nr[gpc] accurate

We're going to be pulling in a chunk of code from NVGPU to fixup our
SMID mappings on Volta and above, which depends on ppc_nr[gpc]
reflecting the actual number of PPCs present, not the maximum number.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: switch to newer style interrupt handler

Ampere.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: move some init to init_exception2()

Ampere.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: move some init to init_rop_exceptions()

Ampere.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: move reset during golden ctx init to fecs_reset()

Ampere.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: wfi after register-bashing golden init

Match RM.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: gpfifo_ctl zero before init

Match RM.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: wait for FE_PWR_MODE_AUTO

This doesn't fix any known issue, but RM started doing it at some point,
so presumably it's needed for something.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: call FECS HALT_PIPE method before RC reset

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: call FECS WFI_GOLDEN_SAVE method

This won't work on Ampere, and, it's questionable whether we should have
been using our FW's method of storing the golden context image with NV's
firmware to begin with.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: stop using NV_PGRAPH_FECS_CTXSW_MAILBOX_CLEAR

This doesn't work on Ampere for some reason, switch to directly modifying
NV_PGRAPH_FECS_CTXSW_MAILBOX instead.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: make global attrib_cb actually global

This was thought to be per-channel initially - it's not.  The backing
pages for the VMM mappings are shared for all channels.

- switches to more straight-forward patch interfaces
- prepares for sub-context support
- this is saving a *sizeable* amount of vram

v2:
- whitespace

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: move misc context patching out of attrib_cb funcs

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: make global bundle_cb actually global

This was thought to be per-channel initially - it's not.  The backing
pages for the VMM mappings are shared for all channels.

- switches to more straight-forward patch interfaces
- prepares for sub-context support

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: make global pagepool actually global

This was thought to be per-channel initially - it's not.  The backing
pages for the VMM mappings are shared for all channels.

- switches to more straight-forward patch interfaces
- prepares for sub-context support

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: generate golden context during first object alloc

Needed for GV100 (and only GV100 for some reason) for WFI_GOLDEN_SAVE.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/gr/gf100-: move some code around to make next commits nicer

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/fifo: expose function to read engine ctxsw status

Needed to support Ampere differences in gr/gf100-:

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/ltc: split color vs depth/stencil zbc counts

These differ on Ampere.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/engine: add HAL for engine-specific rc reset procedure

Will be used to improve gr reset on GF100 and newer.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/sec2: dump tracepc info on halt

- useful to distinguish between different issues.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/acr: use common falcon HS FW code for ACR FWs

Adds context binding and support for FWs with a bootloader to the code
that was added to load VPR scrubber HS binaries, and ports ACR over to
using all of it.

- gv100 split from gp108 to handle FW exit status differences

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/fb/gp102-: unlock VPR right after devinit

Under memory load, instmem allocations could end up in the regions of
VRAM that are inaccessible right after boot, and be corrupted after a
suspend/resume cycle as a result of being restored before booting the
mem unlock firmware.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>