Don't populate the read-only arrays on the stack but instead make
them static const and signed 8 bit ints. Also makes the object code a
little smaller.  Reformat the statements to clear up checkpatch warning.
Signed-off-by: NColin Ian King <colin.i.king@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223120923.239867-1-colin.i.king@gmail.com

Move intel_display_power_well_is_enabled() to intel_power_well.c, as a step
towards making the low-level power well internals (i915_power_well_ops/desc
structs) hidden.

Eventually the call to this function and in general accessing power
wells directly from elsewhere in the driver should be replaced by the
use of power domains.

No functional change.
Suggested-by: NJani Nikula <jani.nikula@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220222165137.1004194-9-imre.deak@intel.com

Add functions to get a power well's actual- and cached-enabled state,
name, domain mask and refcount, as a step towards making the low-level
power well internals (i915_power_well_ops/desc structs) hidden.

No functional change.
Suggested-by: NJani Nikula <jani.nikula@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220222165137.1004194-8-imre.deak@intel.com

Add a function to call a power well's sync_hw() hook, instead of
open-coding the same, as a step towards making the low-level
power well internals (i915_power_well_ops/desc structs) hidden.

The cached-enable state should be always up-to-date, so update it
whenever sync_hw() is called.

No functional change.
Suggested-by: NJani Nikula <jani.nikula@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220222165137.1004194-7-imre.deak@intel.com

Move the power well get/put/enable/disable hooks to the new
intel_display_power_well.c file. The motivation is to reduce the clutter
in intel_display_power.c, keeping the functionality related to power
domains in that file and moving the low-level power well functionality
to intel_display_power_well.c.

No functional change.
Suggested-by: NJani Nikula <jani.nikula@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220222165137.1004194-6-imre.deak@intel.com

Move the i915_power_well_regs struct into i915_power_well_ops. Most of
the power wells use the same ops/regs combination, so this saves some
space and also simplifies the platform power domain->power well
definitions.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220222165137.1004194-5-imre.deak@intel.com

Commit d5ce34da
("drm/i915: Add state verification for the TypeC port mode")
added a verification to the TypeC AUX power well enable()/disable()
hooks to check if the TypeC port related to this power well is properly
locked. If the disabling happens asynchronously the verification is
skipped, since in this case the port is unlocked. The detection of
asnychronous disabling doesn't work as intended though, since the power
well's reference count is always 0 when its disable() hook is called
(and since there won't be any domain reference held for this power well
either, the verification is always skipped); remove the verification
from the disable() hook for now. In the power well's enable() hook the
power well's reference will be always >0 and there won't be any
asynchronous disabling pending for it, so we can drop the async refcount
check from there.

No functional change.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220222165137.1004194-4-imre.deak@intel.com

Instead of open-coding the call of the power wells' enable()/disable()
hooks use the corresponding helper functions. This will also ensure that
the power well's cached-enable state is always up-to-date. Luckily the
lack of this updating hasn't been a problem, since the state either
didn't change (in intel_display_power_set_target_dc_state()), or got
updated subsequently (for vlv_cmnlane_wa(), in the following
intel_power_domains_sync_hw()).
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220222165137.1004194-3-imre.deak@intel.com

The POWER_DOMAIN_TRANSCODER() macro depends on the
POWER_DOMAIN_TRANSCODER_A/B .. DSI_A/C enum values to be consecutive,
move POWER_DOMAIN_TRANSCODER_VDSC_PW2 after these to ensure this. The
wrong order didn't cause a problem, since the DSI_A/C domains are in
always-on power wells on all relevant platforms. The same power well
ends up being enabled/disabled when the VDSC_PW2 domain is selected
incorrectly.

While at it add a code comment about enum values that need to stay
consecutive.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220222165137.1004194-2-imre.deak@intel.com

When calculating pipe_mode and when doing readout we need
to order our steps correctly.

1. We start with adjusted_mode crtc timings being populated
   with the transcoder timings (either via readout or
   compute_config(). These will be per-segment for MSO.
2. For all other uses we want the full crtc timings so
   we ask intel_splitter_adjust_timings() to expand
   the per-segment numbers to their full glory
3. If bigjoiner is used we the divide the full numbers
   down to per-pipe numbers using intel_bigjoiner_adjust_timings()

During readout we also have to reconstruct the adjusted_mode
normal timings (ie. not the crtc_ stuff). These are supposed
to reflect the full timings of the display. So we grab these
between steps 2 and 3.

The "user" mode readout (mainly done for fastboot purposes)
should be whatever mode the user would have used had they
asked us to do a modeset. We want the full timings for this
as the per-segment timings are not suppoesed to be user visible.
Also the user mode normal timings hdisplay/vdisplay need to
match PIPESRC (that is where we get our PIPESRC size
we doing a modeset with a user supplied mode).

And we end up with
- adjusted_mode normal timigns == full timings
- adjusted_mode crtc timings == transcoder timings
  (per-segment timings for MSO, full timings otherwise)
- pipe_mode normal/crtc timings == pipe timings
  (full timings divided by the number of bigjoiner pipes, if any)
- user mode normal timings == full timings with
  hdisplay/vdisplay replaced with PIPESRC size
- user mode crtc timings == full timings

Yes, that is a lot of timings. One day we'll try to remove
some of the ones we don't actually need to keep around...
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-10-ville.syrjala@linux.intel.com

Pull intel_crtc_compute_pipe_mode() out from
intel_crtc_compute_config(). Since it's semi related
we'll suck in the max dotclock/double wide checks in
as well.

And we'll pimp the debugs while at it.
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-9-ville.syrjala@linux.intel.com

intel_crtc_compute_config() doesn't really tell a unified story.
Let's chunk it up into pieces. We'll start with
intel_crtc_compute_pipe_src().
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-8-ville.syrjala@linux.intel.com

Deduplicate the code to convert the full timings to
per-pipe timings for bigjoiner usage.
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-7-ville.syrjala@linux.intel.com

Let's not replicate the same piece of code to expand
the MSO segment timings to full width in many places.
Pull it into a helper
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-6-ville.syrjala@linux.intel.com

Do the s/dev_priv/i915/ and s/pipe_config/crtc_state/ renames
to intel_crtc_compute_config(). I want to start splitting this
up a bit and doing the renames now avoids spreading these old
nameing conventions elsewhere. No functional changes.
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-5-ville.syrjala@linux.intel.com

We just copied over the whole master crtc state, including
cpu_transcoder+has_audio. No need to copy those again.

Also get rid of the unhelpful comment.
Reviewed-by: NAnkit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-4-ville.syrjala@linux.intel.com

Adjust the cursor dst coordinates appripriately when it's on
the bigjoiner slave pipe. intel_atomic_plane_check_clipping()
already did this but with the cursor we discard those results
(apart from uapi.visible and error checks) since the hardware
will be doing the clipping for us.

v2: Rebase due to bigjoiner bitmask usage
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-3-ville.syrjala@linux.intel.com

bigjoiner_pipes==0 leads bigjoiner_master_pipe() to
do BIT(ffs(0)-1) which is undefined behaviour. The code should
actually still work fine since the only place we provoke
that is intel_crtc_bigjoiner_slave_pipes() and it'll bitwise
AND the result with 0, so doesn't really matter what we get
out of bigjoiner_master_pipe(). But best not provoke undefined
behaviour anyway.
Reported-by: Nkernel test robot <oliver.sang@intel.com>
Fixes: a6e7a006 ("drm/i915: Change bigjoiner state tracking to use the pipe bitmask")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-2-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

Checking by >= DISPLAY_VER(12) made sense when the support for Tiger
Lake was added. However now it only leads to wrong behavior when adding
more platforms since it's expected they either don't have DMC to load
or they have their own blob.

Logs from DG2 loading on a CFL host, without having a DMC firmware
defined:

	<6>[    0.000000] DMI: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWR1.R00.X220.B00.2103302221 03/30/2021
	...
	<6>[    2.706607] pci 0000:03:00.0: [8086:56a0] type 00 class 0x030000
	...
	<7>[    6.340397] i915 0000:03:00.0: [drm:intel_dmc_ucode_init [i915]] Loading i915/tgl_dmc_ver2_12.bin
	<7>[    6.341841] i915 0000:03:00.0: [drm:intel_fbc_init [i915]] Sanitized enable_fbc value: 1
	<3>[    6.342432] genirq: Flags mismatch irq 0. 00000080 (i915) vs. 00015a00 (timer)
	<6>[    6.346283] i915 0000:03:00.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12)
	<3>[    6.385756] i915 0000:03:00.0: Device initialization failed (-16)
	<5>[    6.385778] i915 0000:03:00.0: Please file a bug on drm/i915; see https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for details.
	<4>[    6.385782] i915: probe of 0000:03:00.0 failed with error -16

TGL is the only platform left with DISPLAY_VER() == 12 that is not
handled already in the if/else ladder, so handle it specifically.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223210933.3049143-1-lucas.demarchi@intel.com

If one of our PHYs fails to complete calibration, we should skip the
general initialization of the corresponding output.  Most likely this is
going to happen on outputs that don't actually exist on the board; in
theory we should have already decided to skip this output based on the
VBT, but we can't always rely on the VBT being accurate.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223165421.3949883-1-matthew.d.roper@intel.com

Drop the locks around sprite plane register writes. The
lock isn't needed since each plane's register are neatly
contained on their own cachelines.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220210062403.18690-6-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Drop the locks around most primary plane register writes.
The lock isn't needed since each plane's register are neatly
contained on their own cachelines.

The one exception we have to make is DSPADDR/DSPSURF which is
(ab)used to also trigger FBC nukes on pre-snb (since the
hardware doesn't seem to have any dedicated mechanism to
trigger nukes). So we need to keep the lock around it to
protect against the rmw performed by the fbc code.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220210062403.18690-5-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Drop the locks around cursor plane register writes. The
lock isn't needed since each plane's register are neatly
contained on their own cachelines.

The locking did have a secondary effect of disabling
interrupts around the cursor registers writes though.
If we drop that then we open outselves up for sceduling
delays and whatnot while on the middle of the register
writes. That increases the chance of not all the register
writes land during the same frame. For normal atomic
commits this is not a concern as the vblank evade mechanism
anyway disables interrupts around the update, but the legacy
cursor codepath does not. Technically we should do a vblank
evade there as well, but so far no one has bothered to hook
that up. So in the meantime let's put an explicit local irq
disable/enable around the legacy cursor update to keep the
race window minimal.

v2: local_irq_{disable,enable}() for legacy cursor ioctl
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220211092604.393-1-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Drop the locks around most universal plane register writes.
The lock isn't needed since each plane's register are neatly
contained on their own cachelines.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220210062403.18690-3-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

On icl+ all plane registers are armed by PLANE_SURF, so we can
move almost everything over into the update_noarm() hook.

The PLANE_CTL write has to stay in the icl_update_arm() hook though
as it still exhibits the somewhat annoying self-arming behaviour
when the plane transitioning from disabled to enabled.

We could either do a full split for skl+ vs. icl+, or we could try
some other kind of split where we'd eg. keep most things in the skl+
functions and call them from the icl+ functions. I think a full split
is probably the cleaner approach since we've anyway accumulated quite
a bit of icl+ specific things, so that is what I opted to do.

Some i915_update_info stats for tgl:
before:                             after:
Updates: 5043                       Updates: 5043
       |                                   |
   1us |                               1us |
       |**                                 |***
   4us |******                         4us |********
       |**********                         |***********
  16us |***********                   16us |**********
       |****                               |*
  66us |                              66us |
       |                                   |
 262us |                             262us |
       |                                   |
   1ms |                               1ms |
       |                                   |
   4ms |                               4ms |
       |                                   |
  17ms |                              17ms |
       |                                   |
Min update: 3494ns                  Min update: 2983ns
Max update: 49491ns                 Max update: 39986ns
Average update: 18031ns             Average update: 13423ns
Overruns > 100us: 0                 Overruns > 100us: 0
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220210062403.18690-2-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Tile4 in bspec format is 4K tile organized into
64B subtiles with same basic shape as for legacy TileY
which will be supported by Display13.

v2: - Moved Tile4 associating struct for modifier/display to
      the beginning(Imre Deak)
    - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
      checks(Imre Deak)
    - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
      (Imre Deak)

v3: - Rebased patch on top of new changes related to plane_caps.
    - Added static assert to check that PLANE_CTL_TILING_YF
      matches PLANE_CTL_TILING_4(Nanley Chery)
    - Fixed naming and layout description for Tile 4 in drm uapi
      header(Nanley Chery)

v4: - Extracted drm_fourcc changes to separate patch(Nanley Chery)
Reviewed-by: NImre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJuha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220118115544.15116-3-stanislav.lisovskiy@intel.com

Extract the data rate calculation loop out from
intel_bw_atomic_check() to make it a bit less confusing.

v2: Deal with 'bool changed'

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> #v1
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-7-ville.syrjala@linux.intel.com

Declutter intel_bw_atomic_check() a bit by pulling
the max QGV mask calculation out.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-6-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Currently we just leave the old gunk lying around in the crtc
state when userspace asks us to fully disable the crtc. That
doesn't match what the state would be had we never even enabled
the crtc in the first place. So let's make this consistent and
call intel_crtc_prepare_cleared_state() for disabled crtcs as well
(excluding bigjoiner slaves of course which have had their state
copied from the master).

I actually already did this once in commit fff13e63 ("drm/i915:
Clear most of crtc state when disabling the crtc") but then
commit 19f65a3d ("drm/i915: Try to make bigjoiner work in atomic
check") undid it all :(
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220217103221.10405-5-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

For some reason we're flagging that we need to run through the
full modeset calculations (any_ms==true -> do cdclk/etc. checks)
if any crtc got initially flagged for a modeset and is not
enabled via the uapi. No idea why this is here since later on
(after all fastset handling) we do full run through the crtcs
and flag any_ms if anything still needs a full modeset. So let's
just throw out this early weirdo.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220217103221.10405-4-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

Include hw.enable and pipe_mode in the crtc debugfs state dump.
These are fairly fundemental to the operation of the driver
so not seeing them leaves us in the dark.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220217103221.10405-3-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

Let's just dump the "full" hw crtc state in debugs so that we can
see if some stale junk was left behind when the crtc is supposed
to be entirely off.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220217103221.10405-2-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

This reverts commit 9bc34b4d.

Just oopses on most machines.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223081810.19917-1-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>

With some VRR panels, user can turn VRR ON/OFF on the fly from the panel settings.
When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore MSA bit
in the DPCD. Currently the driver parses that onevery HPD but fails to reset
the corresponding VRR Capable Connector property.
Hence the userspace still sees this as VRR Capable panel which is incorrect.

Fix this by explicitly resetting the connector property.

v2: Reset vrr capable if status == connector_disconnected
v3: Use i915 and use bool vrr_capable (Jani Nikula)
v4: Move vrr_capable to after update modes call (Jani N)
Remove the redundant comment (Jan N)

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220215202601.22943-1-manasi.d.navare@intel.com

Add display workaround # 1309179469 , which fixes a PHY hang when
switching from TBT mode to DP-alt/legacy mode. The workaround also
requires an IFWI/PHY firmware change, before that this change has no
effect (the DKL_PCS_DW5/SOFTRESET flag is always cleared).

HSDES: 18018237866
HSDES: 16014473319
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220218122611.767974-1-imre.deak@intel.com

The ICL DSI registers have fairly isolated usage. Split the register
macros to a separate file.

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220217224023.3994777-4-jani.nikula@intel.com

The VLV (including CHV, BXT, and GLK) DSI registers have fairly isolated
usage. Split the register macros to separated files.

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220217224023.3994777-3-jani.nikula@intel.com

Having a separate definition will be useful for splitting VLV and ICL
register files.

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220217224023.3994777-2-jani.nikula@intel.com

The VBT DSI video transfer mode field values have been defined in terms
of the VLV MIPI_VIDEO_MODE_FORMAT register. The ICL DSI code maps that
to ICL DSI_TRANS_FUNC_CONF() register. The values are the same, though
the shift is different.

Make a clean break and disassociate the values from each other. Assume
the values can be different, and translate the VBT value to VLV and ICL
register values as needed. Use the existing macros from intel_bios.h.

This will be useful in splitting the DSI register macros to files by DSI
implementation.

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220217224023.3994777-1-jani.nikula@intel.com

We need to use phy_name() to convert the PHY value into a human-readable
character in the error message.

Fixes: a6a12811 ("drm/i915/dg2: Wait for SNPS PHY calibration during display init")
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NSwathi Dhanavanthri <swathi.dhanavanthri@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220215163545.2175730-1-matthew.d.roper@intel.com
(cherry picked from commit 84073e56)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>