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

v2: Sort includes (Matt)

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

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

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

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

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

The mock device creation was the only place that needed to modify
platform_engine_mask and memory_regions runtime. With mock_info in place
for mock devices, we can move them to device info.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2083fb26468eef13defb9b70523f7f707fc93bad.1687878757.git.jani.nikula@intel.com

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

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

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

That function is not defined anywhere.
Signed-off-by: NGustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: NRavi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230613214658.1099759-1-gustavo.sousa@intel.com

Fix Sphinx warning about unexpected indent.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230621123156.14907-2-jani.nikula@intel.com

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

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

Use the Sphinx C domain namespace for the rfc document to fix this.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230621123156.14907-1-jani.nikula@intel.com

DC states are disabled / re-enabled around each modeset, which may lead
to a needless off->on->off toggling of the DC_off power well. This has
some overhead as toggling DC states involves running a DMC firmware
handler and also running a periodic firmware handler while DC states are
enabled. The limit of when DC states have a benefit is at 30 FPS (using
DC3co) and below 30 FPS (using DC5/6), where the firmware can actually
disable clocks / power off power wells. Accordingly delay powering off
the DC_off powerwell (which re-enables DC states) by 17 ms at the end of
a modeset to avoid the above overhead at or above 60 FPS.
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616185104.2502003-4-imre.deak@intel.com

Add support for specifying a delay different than the current 100 ms
default for powering off a display power domain. This is needed by the
next patch which delays re-enabling DC states during modesets to avoid
the off->on->off toggling overhead of the DC_off power well, but does
this using a < 100 ms delay for a better utilization of DC power saving
states.
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616185104.2502003-3-imre.deak@intel.com

Remove the forward declarations for enums and structs from display power
header files that aren't used in prototypes.
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616185104.2502003-2-imre.deak@intel.com

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

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

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

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

--v2
-correcttypo in commit header

--v3
-correct the other typo in commit header [Jani]
Signed-off-by: NSuraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: NChaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: NAnkit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230621085453.1996166-1-suraj.kandpal@intel.com

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

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

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

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

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

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

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

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

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

Add vswing table to support DP 1.4 for C20 phy.

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

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

Update preset 15 setting to align the latest bspec value.

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

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

v2: Account for DDI-E in strap detection
    Keep to the old CRT->DDI init order
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616140820.11726-8-ville.syrjala@linux.intel.com

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

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

DSI is still a mess. For now just check for the relevant
platforms explicitly.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616140820.11726-7-ville.syrjala@linux.intel.com

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

And add a similar thing for g4x HDMI, mainly because on g4x
itsefl port D only supports DP but not SDVO/HDMI. For the
other platforms the generic port_mask check should actually
be sufficient, but since we're here might as well list the
ports.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616140820.11726-6-ville.syrjala@linux.intel.com

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

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

For DVO and HSW/BDW CRT port I just threw the assert in
there for good measure.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616140820.11726-5-ville.syrjala@linux.intel.com

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

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

v2: Relocate to the new place
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616140820.11726-4-ville.syrjala@linux.intel.com

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

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

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

v2: Fix TC5 vs. TC6 mixup on TGL (Jani)
    Drop DDI C for now on TGL, and add a FIXME (Jani)
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616140820.11726-3-ville.syrjala@linux.intel.com

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

Seems to have been accidentally left behind when the
skl+ stuff got split out in commit 097d9e90
("drm/i915/display: remove strap checks from gen 9").
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616140820.11726-2-ville.syrjala@linux.intel.com

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

[Before enabling DC states:]

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

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

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

Bpsec: 49193

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

All known issues fixed now, so re-enable PSR1 on hsw/bdw.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-14-ville.syrjala@linux.intel.comReviewed-by: NJouni Högander <jouni.hogander@intel.com>

Can't see why we'd want the sprite blocking PSR entry.
Mask it out.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-13-ville.syrjala@linux.intel.comReviewed-by: NJouni Högander <jouni.hogander@intel.com>

WA 0479 says: "Do not skip both TP1 and TP2/TP3". Let's just
stick the minimum 100us TP2/3 time in there to avoid that.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-12-ville.syrjala@linux.intel.comReviewed-by: NJouni Högander <jouni.hogander@intel.com>

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

Note that WaMaskMMIOWriteForPSR asks us to mask this on bdw, but
that won't work since we need those CURSURFLIVE tricks. Observations
on actual hardware show that this causes one extra PSR exit ~every
10 seconds, which is pretty much irrelevant. I suspect this is
due to the pcode poking at IPS_CTL. Disabling IPS does not stop it
however, so either I'm wrong or pcode pokes at the register
regardless of whether it's actually trying to enable/disable IPS.
Also when the machine is busy (eg. just running 'find /') these
extra PSR exits cease, which again points at pcode or some other
PM entity as being the culprit.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-11-ville.syrjala@linux.intel.comReviewed-by: NJouni Högander <jouni.hogander@intel.com>

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

Note that I was unable to observe any change in hardware
behviour due to this bit on HSW. But let's do this anyway
in case it matters in some cases, and the corresponding bit
on BDW is abolutely critical as without it the hardware
won't generate any vblanks whatsoever after PSR exit.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-10-ville.syrjala@linux.intel.comReviewed-by: NJouni Högander <jouni.hogander@intel.com>

Implement WaPsrDPAMaskVBlankInSRD:hsw, which makes the hardware
generate the extra vblank between link training and first frame
being transmitted. This is the same thing that's controlled by
TRANS_CHICKEN[21] on skl+ (but due to the funky double buffering
it's effectively always at the rest value after DC5 exit). So
for consistent behaviour we want every platform to generate said
vblank. BDW is already setting this up correctly.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-9-ville.syrjala@linux.intel.comReviewed-by: NJouni Högander <jouni.hogander@intel.com>

Add the PSR interrupt handling code back for HSW. Looks like
the removal was never completed anyway since the irq setup
code was lest untouched.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-8-ville.syrjala@linux.intel.comReviewed-by: NJouni Högander <jouni.hogander@intel.com>

Deal with HSW/BDW in transcoder_has_psr2().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-7-ville.syrjala@linux.intel.comReviewed-by: NJouni Högander <jouni.hogander@intel.com>

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

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

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

Add back hsw'w special SRD/PSR1 registers.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-5-ville.syrjala@linux.intel.comReviewed-by: NJouni Högander <jouni.hogander@intel.com>

In preparation for re-introducing HSW's different PSR1 register
offeets let's just wrap all the registers into functions.
Avoids having to make the register macros more complex.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-4-ville.syrjala@linux.intel.comReviewed-by: NJouni Högander <jouni.hogander@intel.com>

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

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

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

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

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

TODO: I suspect most gt stuff doesn't need this and we should
      finish moving all of them from init_clock_gating() to
      a more appropriate place...
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230609141404.12729-2-ville.syrjala@linux.intel.comReviewed-by: NJouni Högander <jouni.hogander@intel.com>