128b/132b supports using 64 slots starting from 0, while 8b/10b reserves
slot 0 for metadata.

Commit d6c6a76f ("drm: Update MST First Link Slot Information Based
on Encoding Format") added support for updating the topology state
accordingly, and commit 41724ea2 ("drm/amd/display: Add DP 2.0 MST
DM Support") started using it in the amd driver.

This feels more than a little cumbersome, especially updating the
information in atomic check. For i915, add the update to MST connector
.compute_config hook rather than iterating over all MST managers and
connectors in global mode config .atomic_check. Fingers crossed.

v3:
- Propagate errors from intel_dp_mst_update_slots() (Ville)

v2:
- Update in .compute_config() not .atomic_check (Ville)

Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Lyude Paul <lyude@redhat.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/20220208152317.3019070-1-jani.nikula@intel.com

Abstract link status check to a function that takes 128b/132b and 8b/10b
into account, and use it. Also dump link status on failures.

Cc: Uma Shankar <uma.shankar@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>
Link: https://patchwork.freedesktop.org/patch/msgid/cec395d435679a290a1c35fcbfc54555101bfad1.1643878928.git.jani.nikula@intel.com

The DP 2.0 errata completely overhauls the 128b/132b link training, with
no provisions for backward compatibility with the original DP 2.0
specification.

The changes are too intrusive to consider reusing the same code for both
8b/10b and 128b/132b, mainly because the LTTPR channel equalisation is
done concurrently instead of serialized.

NOTES:

* It's a bit unclear when to wait for DP_INTERLANE_ALIGN_DONE and
  per-lane DP_LANE_SYMBOL_LOCKED. Figure xx4 in the SCR implies the
  LANEx_CHANNEL_EQ_DONE sequence may end with either 0x77,0x77,0x85 *or*
  0x33,0x33,0x84 (for four lane configuration in DPCD 0x202..0x204)
  i.e. without the above bits set. Text elsewhere seems contradictory or
  incomplete.

* We read entire link status (6 bytes) everywhere instead of individual
  DPCD addresses.

* There are some subtle ambiguities or contradictions in the order of
  some DPCD access and TPS signal enables/disables. It's also not clear
  whether these are significant.

v4:
- Wait for intra-hop clear after link training end (Ville)
- Wait instead of single check for intra-hop clear before link train

v3:
- Use msecs_to_jiffies_timeout() (Ville)
- Read status at the beginning of interlane align done loop (Ville)
- Try to simplify timeout flag use where possible (Ville)

v2:
- Always try one last time after timeouts to avoid races (Ville)
- Extend timeout to cover the entire LANEx_EQ_DONE sequence (Ville)
- Also check for eq interlane align done in LANEx_CDS_DONE Sequence (Ville)
- Check for Intra-hop status before link training

Cc: Uma Shankar <uma.shankar@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>
Link: https://patchwork.freedesktop.org/patch/msgid/20220208143209.2997337-1-jani.nikula@intel.com

Call it from the higher level function, as it will be shared between two
code paths.

Cc: Uma Shankar <uma.shankar@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>
Link: https://patchwork.freedesktop.org/patch/msgid/c0fffbf7213c09e42be9875d38d3001e0026b063.1643878928.git.jani.nikula@intel.com

Add some of the new additions from DP 2.0 E11.

Cc: Uma Shankar <uma.shankar@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>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/ec9c1b94858de36b9f4ef6c197effa4ca667afc3.1643878928.git.jani.nikula@intel.com

The DP 2.0 errata redefines link training. There are some new status
bits, and some of the old ones need to be checked independently. Add
helpers to do this.

Cc: Uma Shankar <uma.shankar@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>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/5a46260d1f171fed46d0ab8fe4b6499abd65ce24.1643878928.git.jani.nikula@intel.com

The DP 2.0 errata changes DP_128B132B_TRAINING_AUX_RD_INTERVAL (DPCD
0x2216) completely. Add a new function to read that. Follow-up will need
to clean up existing functions.

v2: fix reversed interpretation of bit 7 meaning (Uma)

Cc: Uma Shankar <uma.shankar@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>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/22f6637194c9edb22b6a84be82dd385550dbb958.1643878928.git.jani.nikula@intel.com

We lost the required >>16 when I refactored the FBC plane state
checks. Bring it back so the check does what it's supposed to.

Cc: Mika Kahola <mika.kahola@intel.com>
Fixes: 2e6c99f8 ("drm/i915/fbc: Nuke lots of crap from intel_fbc_state_cache")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220210103107.24492-1-ville.syrjala@linux.intel.com


Reviewed-by: Mika Kahola <mika.kahola@intel.com>

Start debug logging about the presence of the new Mailbox #2 for
backlight. Actual support is to be added later.

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>
Link: https://patchwork.freedesktop.org/patch/msgid/42fd9cd777c5cc9a8d48db9dd8306924c735918e.1644489329.git.jani.nikula@intel.com

Opregion Mailbox #2 is obsolete for SWSCI usage in opregion v2.x, and
repurposed in opregion v3.x. Warn about obsole mailbox presence in v2.x,
and ignore with an error for v3.x.

v2: Demote drm_warn() to drm_dbg() on opregion v2.x

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>
Link: https://patchwork.freedesktop.org/patch/msgid/20220210161603.647254-1-jani.nikula@intel.com

Newer platforms aren't supposed to have mailbox #2 or SWSCI
support. Bail out early from encoder notify if that is the case,
skipping the out-of-bounds checks and debug messages.

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>
Link: https://patchwork.freedesktop.org/patch/msgid/82f63313057ed2d96856b3f8d76536826a897bc7.1644489329.git.jani.nikula@intel.com

Add a reusable function for checking the SWSCI function.

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>
Link: https://patchwork.freedesktop.org/patch/msgid/778f8716ec44adad3cf95a7bb327a7c8e981291d.1644489329.git.jani.nikula@intel.com

The mapping from enum port to whatever port numbering scheme is used by
the SWSCI Display Power State Notification is odd, and the memory of it
has faded. In any case, the parameter only has space for ports numbered
[0..4], and UBSAN reports bit shift beyond it when the platform has port
F or more.

Since the SWSCI functionality is supposed to be obsolete for new
platforms (i.e. ones that might have port F or more), just bail out
early if the mapped and mangled port number is beyond what the Display
Power State Notification can support.

Fixes: 9c4b0a68 ("drm/i915: add opregion function to notify bios of encoder enable/disable")
Cc: <stable@vger.kernel.org> # v3.13+
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4800


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/cc363f42d6b5a5932b6d218fefcc8bdfb15dbbe5.1644489329.git.jani.nikula@intel.com

The macros are more at home in i915_driver.[ch].

v2: Rebase

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/20220209123121.3337496-1-jani.nikula@intel.com

Underscore prefix the index macros, and place
INTEL_HWS_CSB_WRITE_INDEX() as a macro next to them, to declutter
i915_drv.h.

v2: Don't underscore the index macros (Tvrtko)

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

IPS must be disabled prior to disabling the last plane (excluding
the cursor). Make the code do that instead of assuming the primary
plane would be the last one. This is probably 100% theoretical
as the BIOS should never light up the other planes anyway. But
no harm in making the code totally consistent.

Also let's update the ips_enabled flag in the crtc state afterwards
so that the first atomic commit has accurate information about
the state of IPS.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-6-ville.syrjala@linux.intel.com


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

Pull the IPS state readout into hsw_ips.c.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-5-ville.syrjala@linux.intel.com


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

IPS is a pretty well isolated feature. Move the relevant code
to a separate file from polluting intel_display.c.

I stuck to the hsw_ips name since that's what the function were
already using, and also to avoid confusion with the ILK
"Intelligen Power Sharing"/intel_ips GPU turbo stuff.

And let's also do the s/dev_priv/i915/ rename while touching
most of the code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-4-ville.syrjala@linux.intel.com


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

No reason the caller of the IPS pre/post update hooks should
be responsible for the actual IPS enab/disable. Just pull those
calls into the pre/post update hooks themselves. And while
at it let's adjust the function naming a bit to have a consistent
namespace.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-3-ville.syrjala@linux.intel.com


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

Follow the modern state+crtc calling convention for the IPS
code as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-2-ville.syrjala@linux.intel.com


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

Hoist the IPS related vblank waits one level up. Later on we'll
want to consolidate all the potential pre-plane update vblank
waits into one so we can't be hiding any in low level code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-1-ville.syrjala@linux.intel.com


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

The struct is only needed in intel_pm.c, move it there.

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/63779ac0472895803113180818ecadc22c10369e.1643896905.git.jani.nikula@intel.com

The struct is only needed in intel_dpll.c, move it there.

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/fedb27386cbad2b162d83a706273dd8ad9e8eed2.1643896905.git.jani.nikula@intel.com

Avoid referencing the function pointer directly to be able to abstract
the call better.

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/12ac40c1ef9915fe680c6657b603b08be022626b.1643896905.git.jani.nikula@intel.com

The struct is only needed in intel_fdi.c, move it there.

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/a6c524a9abb74be9b4d6a084de5461404b823a10.1643896905.git.jani.nikula@intel.com

With intel_hpd_irq_setup() in i915_irq.c, struct intel_hotplug_funcs is
also only needed there.

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/9a10dbca7ad298dde62b83f76e0df43a67bceeef.1643896905.git.jani.nikula@intel.com

The struct is only needed in intel_color.c, move it there.

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/68cf44fab55c047253c3ed87f8afcf0a86fa157a.1643896905.git.jani.nikula@intel.com

Group the forward declarations in i915_drv.h together near the top, like
in other header files, and sort.

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/67f2ed8a9166daa891aa6d89f93eb629145d1c15.1643896905.git.jani.nikula@intel.com

The bogus loop from compute_dbuf_slices() was copied into
check_mbus_joined() as well. So this lookup is wrong as well.
Fix it.

Cc: stable@vger.kernel.org
Fixes: f4dc0086 ("drm/i915/adl_p: MBUS programming")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220207132700.481-2-ville.syrjala@linux.intel.com


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

Apparently I totally fumbled the loop condition when I
removed the ARRAY_SIZE() stuff from the dbuf slice config
lookup. Comparing the loop index with the active_pipes bitmask
is utter nonsense, what we want to do is check to see if the
mask is zero or not.

Note that the code actually ended up working correctly despite
the fumble, up until commit eef17395 ("drm/i915: Allow
!join_mbus cases for adlp+ dbuf configuration") when things
broke for real.

Cc: stable@vger.kernel.org
Fixes: 05e8155a ("drm/i915: Use a sentinel to terminate the dbuf slice arrays")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220207132700.481-1-ville.syrjala@linux.intel.com


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

Rename struct dma_buf_map to struct iosys_map and corresponding APIs.
Over time dma-buf-map grew up to more functionality than the one used by
dma-buf: in fact it's just a shim layer to abstract system memory, that
can be accessed via regular load and store, from IO memory that needs to
be acessed via arch helpers.

The idea is to extend this API so it can fulfill other needs, internal
to a single driver. Example: in the i915 driver it's desired to share
the implementation for integrated graphics, which uses mostly system
memory, with discrete graphics, which may need to access IO memory.

The conversion was mostly done with the following semantic patch:

	@r1@
	@@
	- struct dma_buf_map
	+ struct iosys_map

	@r2@
	@@
	(
	- DMA_BUF_MAP_INIT_VADDR
	+ IOSYS_MAP_INIT_VADDR
	|
	- dma_buf_map_set_vaddr
	+ iosys_map_set_vaddr
	|
	- dma_buf_map_set_vaddr_iomem
	+ iosys_map_set_vaddr_iomem
	|
	- dma_buf_map_is_equal
	+ iosys_map_is_equal
	|
	- dma_buf_map_is_null
	+ iosys_map_is_null
	|
	- dma_buf_map_is_set
	+ iosys_map_is_set
	|
	- dma_buf_map_clear
	+ iosys_map_clear
	|
	- dma_buf_map_memcpy_to
	+ iosys_map_memcpy_to
	|
	- dma_buf_map_incr
	+ iosys_map_incr
	)

	@@
	@@
	- #include <linux/dma-buf-map.h>
	+ #include <linux/iosys-map.h>

Then some files had their includes adjusted and some comments were
update to remove mentions to dma-buf-map.

Since this is not specific to dma-buf anymore, move the documentation to
the "Bus-Independent Device Accesses" section.

v2:
  - Squash patches

v3:
  - Fix wrong removal of dma-buf.h from MAINTAINERS
  - Move documentation from dma-buf.rst to device-io.rst

v4:
  - Change documentation title and level

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220204170541.829227-1-lucas.demarchi@intel.com

Remove the trailing semicolon, as correctly warned by checkpatch:

	-:1189: WARNING:TRAILING_SEMICOLON: macros should not use a trailing semicolon
	#1189: FILE: drivers/gpu/drm/i915/intel_device_info.c:119:
	+#define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name, yesno(info->display.name));

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

On TGL/RKL the BIOS likes to use some kind of bogus DBUF layout
that doesn't match what the spec recommends. With a single active
pipe that is not going to be a problem, but with multiple pipes
active skl_commit_modeset_enables() goes into an infinite loop
since it can't figure out any order in which it can commit the
pipes without causing DBUF overlaps between the planes.

We'd need some kind of extra DBUF defrag stage in between to
make the transition possible. But that is clearly way too complex
a solution, so in the name of simplicity let's just sanitize the
DBUF state by simply turning off all planes when we detect a
pipe encroaching on its neighbours' DBUF slices. We only have
to disable the primary planes as all other planes should have
already been disabled (if they somehow were enabled) by
earlier sanitization steps.

And for good measure let's also sanitize in case the DBUF
allocations of the pipes already seem to overlap each other.

Cc: <stable@vger.kernel.org> # v5.14+
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4762


Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-3-ville.syrjala@linux.intel.com


Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

During readout we cannot assume the planes are actually using the
slices they are supposed to use. The BIOS may have misprogrammed
things and put the planes onto the wrong dbuf slices. So let's
do the readout more carefully to make sure we really know which
dbuf slices are actually in use by the pipe at the time.

Cc: <stable@vger.kernel.org> # v5.14+
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-2-ville.syrjala@linux.intel.com


Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Reintroduce the !join_mbus single pipe cases for adlp+.

Due to the mbus relative dbuf offsets in PLANE_BUF_CFG we
need to know the actual slices used by the pipe when doing
readout, even when mbus joining isn't enabled. Accurate
readout will be needed to properly sanitize invalid BIOS
dbuf configurations.

This will also make it much easier to play around with the
!join_mbus configs for testin/workaround purposes.

Cc: <stable@vger.kernel.org> # v5.14+
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-1-ville.syrjala@linux.intel.com


Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Make sure all unused power wells left enabled by BIOS get disabled
during driver loading and system resume.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5028


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

Architectures others than x86 have a stub implementation calling
WARN_ON_ONCE(). The appropriate headers need to be included, otherwise
the header-test target will fail with:

  HDRTEST drivers/gpu/drm/i915/i915_mm.h
In file included from <command-line>:
./drivers/gpu/drm/i915/i915_mm.h: In function ‘remap_io_mapping’:
./drivers/gpu/drm/i915/i915_mm.h:26:2: error: implicit declaration of function ‘WARN_ON_ONCE’ [-Werror=implicit-function-declaration]
   26 |  WARN_ON_ONCE(1);
      |  ^~~~~~~~~~~~

v2: Do not include <linux/printk.h> since call to pr_err() has been
removed

Fixes: 67c430bb ("drm/i915: Skip remap_io_mapping() for non-x86 platforms")
Cc: Siva Mullati <siva.mullati@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Siva Mullati <siva.mullati@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220131165926.3230642-3-lucas.demarchi@intel.com

Following what was done in drm_cache.c, when the stub for
remap_io_mapping() was added in commit 67c430bb ("drm/i915: Skip
remap_io_mapping() for non-x86 platforms"), it included a log message
with pr_err().  However just the warning is already enough and switching
to WARN_ONCE() allows us to keep the log message while avoiding log
spam.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220131165926.3230642-4-lucas.demarchi@intel.com

A couple hunks didn't get applied while resolving the conflicts on
commit 0d6419e9 ("drm/i915: Move GT registers to their own header
file").  Add the second half of the patch as a follow-up commit.

Fixes: 0d6419e9 ("drm/i915: Move GT registers to their own header file")
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220127234334.4016964-6-matthew.d.roper@intel.com

Several of our i915 header files, have been including i915_reg.h.  This
means that any change to i915_reg.h will trigger a full rebuild of
pretty much every file of the driver, even those that don't have any
kind of register access.  Let's delete the i915_reg.h include from all
headers and add an explicit include from the .c files that truly
need the register definitions; those that need a definition of
i915_reg_t for a function definition can get it from i915_reg_defs.h
instead.

We also remove two non-register #define's (VLV_DISPLAY_BASE and
GEN12_SFC_DONE_MAX) into i915_reg_defs.h to allow us to drop the
i915_reg.h include from a couple of headers.

There's probably a lot more header dependency optimization possible, but
the changes here roughly cut the number of files compiled after 'touch
i915_reg.h' in half --- a good first step.

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